top of page

Reflecting upon Coursera's C++ MOOC

  • Writer: Kris Pearson
    Kris Pearson
  • Dec 23, 2017
  • 4 min read


Having completed my first MOOC (Massive Open Online Course) I'm eager to reflect upon the experience whilst also storing a record of some of the more prominent lessons learned during the course.


I enrolled on the course titled "C++ for C Programmers , Part A" which was hosted by Coursera and presented by Ira Pohl of the University of California, Santa Cruz, on the 20th of November this year with the intent of bolstering my experience of programming sans game engine.


As it happens, I have never programmed in C, but being already accustomed to C++, I concluded that this course would indeed suit me, if only to provide reason and explanation for the practices which I have already accumulated from other sources such as forums, tutorials and prior experience in java script and C++.


So, how useful was the course?


Well, initially it has to be said that I found the first week to be too simple, as it started with the basics, it seemed, and introduced no concepts that were new to me. Several hours of lectures, followed by a simple piece of homework which concerned the conversion of a C program, which was provided by the course, into C++.


The following weeks however, averted this becoming a trend as the lectures became more in depth, and the requirements for completing each week were far more demanding.

Students were first requested to develop a program which would randomly generate a graph, before then applying Dijkstra's path-finding algorithm to the resulting graph, with Prim's and Kruskal's minimum spanning tree(MST) algorithms shortly to follow.


Outside of grid based path finding; I wasn't overly familiar with graph theory, but the concept of MSTs was completely new to me. The course requested that we modify our Graph generating code to accommodate data input from a text file (as opposed to randomly generating a graph) and then use this data to programmatically construct the MST.


An MST differs from a shortest path in that it is more concerned with establishing a network of points with the smallest possible cost to move between all of the nodes of the Graph, rather than the cost for moving from one particular node to another.


The 'travelling salesman problem' was most suited for providing an explanation for the potential uses of such algorithms, which also leads me to consider whether contemporary delivery firms implement such algorithms when plotting the distribution of parcels, for instance.


One real world application that I've seen proposed is in the laying of cables by telecommunications companies, who want to connect their customers with the minimum amount of cable between their properties by creating a network.

Another is involved in the protocols dictating computer networks, where the 'cost' is concerned with the speed and efficiency of data transferal.


One idea that the course repeatedly pushed is to program while considering other programmers; who might be using your code, classes and functions. One example given was to use the const keyword to suggest intent.


Previously, I had understood const to be an efficiency saving device, and that by putting such constraints on the mutability of values, the compiler is provided information to sometimes be able make efficiency savings - however minor.


Now, it has to be said, that my eyes are open to the idea of const-correctness, and I'm even more minded to use const when handling data with no intent to modify its values directly - efficiency savings or no. I still can't find hard evidence on the business of efficiency, and I'm not currently minded to attempt to profile this either, as using const for its actual purpose is more than enough reason to use it.


Another enlightening example is the use of operator overloading.

I was, of course, already familiar with overloading, but it had never even occurred to me most of the operators used every day could be overloaded to provide functionality to suit the needs of a class.


This should again be done with other programmers in mind, who have certain expectations of how operators overloaded to work with a class should behave, and straying from these inferred understandings could promote confusion and irritation, to say the least.


An example of this created by me was used in the homework for this course.

When creating Edges - the connections between Nodes - for my Graph, I performed a check to see whether the Edge already existed, so as not to create the same Edge twice. I did this by overloading the '==' operator to compare the two Edges.


inline friend bool operator==(const Edge& edge1, const Edge& edge2) {
return (edge1.endNode == edge2.endNode &&
edge1.startNode == edge2.startNode);
};

It has to be said, that the course did very little hand holding, and largely took on the role of introducing tools and ideas, and relied upon the learners to experiment and research further into them in order to successfully combine them all to complete the tasks assigned.


Encapsulation and re-usability was only ever briefly touched upon, and I would have appreciated more focus on the subject of object orientation and inheritance though and, while generics where covered at times it wouldn't have hurt to have some tasks on the subject going towards the final grade.


Much of the graded work is also peer reviewed, which was both a boon and bane.

On the one hand; your work could be reviewed by someone far more technically competent than yourself - who may then go on to provide you with useful insight and tips for improving your practice. You also have the opportunity to review the code of others and pick up on how their approaches differed from your own - which could also be massively insightful.

On the other hand you might receive lackluster and unhelpful reviews. Twice I received single line comments, where one would expect a semi-detailed breakdown of the reviewer's opinion of your code. I have seen this problem echoed by others on the site forums.


Overall, the course was focused and felt like a complete module - allowing the learners to develop a single program, with new requirements added for said program each week to keep us adapting and learning.


Part B of the course begins in January, and I'm certainly inclined to enroll for that too, which should testament enough for my opinion of the course.



 
 
 

Recent Posts

See All
Greywacke, signing in.

Fist things first - the name - why "GreyWacke"? Well, this is actually a nod to myself in the alternate reality in which I chose a path...

 
 

Comments


bottom of page