Mentoring Junior Developers in C++

Question

I've been tasked with trying to come up with a topic to research and present for my team to deal with areas of C++ that might be tricky for more junior developers who mainly have dealt with C coding. I was wondering if anyone had ideas for topics for these kind of talks and then if the resulting slide deck of my talks would be useful for anyone.

Answer 1

If the junior developers are mainly used to C, then I'd start with introducing the concept of a class and data encapsulation. That's pretty key in object-oriented programming (which is how C++ is most often used).

That will allow you to later transition into related topics such as object lifetime management.

One place to start is a review (or perhaps introduction) of how you'd implement an object-oriented architecture using just C. Then transition to implementing the same functionality using the additional constructs available only in C++.

Answer 2

Based on my own experience and pitfalls from somebody that learnt first C and C++ later (still learning), STL is important topic, people from C (like I was) have the habit to build every thing from scratch, and forget to check that there's lot of 'ready to be used' stuff in C++ STL.

Answer 3

If the focus is really on areas that might be tricky, go for Herb Sutter's Guru of the Week questions (and the extended versions in his books). These are focused on widely used C++ constructs that still behave somewhat unexpected. However, your team should already know the basics of C++ and OOP in general.

Answer 4

Here are some things that come to mind, mostly from watching C programming colleagues try to write C++: :)

• Always use standard C++ casts instead of C "sledgehammer" casts.
• Don't abuse macros. Templates are almost always a better solution. YMMV :)
• Don't reinvent the wheel. Take advantage of STL algorithms and containers.
• No need to declare all variables at the beginning of the scope.
• Operator overloading
• Basic inheritance, and potential pitfalls (slicing during copy, etc)
• Run-time polymorhphism vs compile-time polymorphism
• Always use new/delete instead of malloc/free.
• Always use std::vector<> instead of dynamically allocated arrays.
• Always use std::string instead of C strings.
• RAII

EDIT: s/prefer/always use/g per Kornel's suggestion.

Answer 5

Maybe you're looking for very specific areas of the C++ language.

Though in my experience with people coming from from C, one of the things junior developers will face when exposed to C++ is object orientation. Introducing them to OOP and why we're doing OOP is often a good start. Show them this , or atleast the essence of that talk.

Answer 6

RAII would be my suggestion. And by this I don't just mean smart pointers, but the notion that every resource acquisition should be tied to a local object (stack-allocated) object so that it is automatically freed again. In fact, to drive the lesson home, I'd probably explicitly avoid smart pointers because they only utilize half the idiom -- they still point to an object you allocated yourself with new -- ideally, you shouldn't even do that, as the object should perform whatever allocations it needs itself, in its constructor.

Walk them through writing some small simple application without any calls to new/delete/malloc/free (and, to a large extent, pointers as well) except those found in the constructors/destructors of their classes. Perhaps developing a custom string class would be a good example (since they'll be used to the pain of string handling in C)

Force them to get used to the idea that instead of dynamically allocating memory and manually tracking its lifetime, the object can typically be placed in a std::vector, or if an object needs to dynamically allocate memory, or otherwise acquire some special resource that must be freed again, it should be wrapped in a class with RAII semantics.

Then expand those classes to provide well-defined copy/assignment/swap operations, so they end up with a class that is as simple to use as the STL ones: one which doesn't require any explicit memory management at all, which can be constructed and copied and manipulated as much as you like, and which will never leak resources or otherwise stop working.

Of course, all of this presumes that they're already familiar with the basic building blocks of the language, such as classes, operator overloading and probably also templates. Depending on their level, it may be better to simply teach them some of the basics, like OOP or an introduction to the STL or to templates.