Chevron Left
Back to Interacting with the System and Managing Memory

Interacting with the System and Managing Memory, Duke University

4.2
19 ratings
5 reviews

About this Course

The final course in the specialization Introduction to Programming in C will teach you powerful new programming techniques for interacting with the user and the system and dynamically allocating memory. You will learn more sophisticated uses for pointers, such as strings and multidimensional arrays, as well as how to write programs that read and write files and take input from the user. Learning about dynamic memory allocation will allow your programs to perform complex tasks that will be applied in the final part of the specialization project: a Monte Carlo simulation for calculating poker hand probabilities....
Filter by:

5 Reviews

By Dimitris Katramados

Dec 08, 2018

The help in the forum is problematic. You are waiting many days to get a reply in case you get stuck.

By Dhiego Santanna da Silva

Nov 18, 2018

Very challenging course.

By Igor Gurovich

Sep 21, 2018

Great 4 courses in C language programming. The courses cover a lot of ground - basics of C, emacs, valgrind, memory allocation, deallocation, C pointers, data structures, etc. The exercises are quite challenging sometimes, underscore importance of testing. Well done!

By Douglas Heatherly

Sep 17, 2018

The 4th course in the specialization was great. The programming project is challenging enough to keep you interested and learning while not so challenging that it can't be completed with the skills learned. Great course.

By Stephen Link

Jun 10, 2018

This course it the 4th and final course in the "Introduction to Programming in C" specialization from Duke University here on Coursera. This review will be for this course in particular and the specialization as a whole since I see no other way to review the entire specialization. First comes the good things. This course reinforced what I learned about pointers in the previous course and it also showed me how to get my C programs to accept input from the command line and how to make those programs read/write to/from other files in a system. If I look at the specialization as a whole it reinforced C basics (which I already knew going in), really improved my understanding of pointers in general, gave me a basic understanding of Makefiles, as well as all the other things I've already mentioned. From a standpoint of understanding the C language I was very pleased with what I learned here.It isn't all sunshine and roses however. This specialization in general, and the final projects for each course in particular, are an exercise in frustration. The general problem with this course, and the entire series, is that your connection to server where you do all of your work is prone to kick you out, seemingly at random, with no notice whatsoever. Also, once you're kicked out, there can sometimes be delays before you can get back in again. I've encountered this on multiple networks, web browsers, and operating systems. I would STRONGLY recommend setting up Cygwin (if you run Windows), or copying the project over to your computer if you're running Mac or Linux, and doing your work locally. Then copy it back to the server to submit for grading. While this is inconvenient it still isn't as bad as being in the middle of your project and suddenly losing all ability to work on it.The final projects for the courses are the worst. All grading is done automatically by scripts on the host machine. When your program fails, and it will fail, you aren't given enough information to be able to correct it. For example, prior to submitting one program I verified it against all of the supplied test cases and also verified with valgrind that it did not have any memory errors. When I submitted it the grader informed me that valgrind detected memory errors. Where were these errors? What sort of errors were they? I didn't know because I didn't have access to the valgrind output from the grader. What input condition led to these errors? I had no idea because I can't see what input the grader provides to my code. So I know that something is wrong but I don't know what it is or even what causes it to happen. And I'm supposed to fix this somehow?On another program the grader only told me that a particular line number in my code's output did not match the expected value. What was the expected output? I have no clue as this isn't listed in project documentation or grader feedback. What was my code's output? No idea as I don't know what input condition led to this problem in the first place. Once again I'm left guessing as to what might be wrong and what might have caused the problem to appear. Due to this lack of feedback I could not have passed this course or the previous one in the series if I hadn't found the instructors' email addresses and worked directly with them on the projects. This really bothers me as I've made a living for many years doing testing and QA work on a variety of hardware and software. If I submit a bug and all it says is "something is wrong" I can expect to hear from the designer/programmer asking for more information. If they ask me what input I gave the program, or what power level I applied to a device under test, and I tell them to guess - I can expect to hear from my supervisor and probably theirs too. The feedback you get from the grader is simply inadequate and unprofessional. Improving this one aspect would take this course, and the entire specialization, up to 5 star status.