Slashdot Mirror
How Much C++ Should You Know For an Entry-Level C++ Job?
Nerval's Lobster writes: How much C++ do you need to know to land an entry-level job that's heavy in C++? That's a question Dice posed to several developers. While the exact topic was C++, the broader question of "How much X do you actually need to know to make money off it?" could also apply to any number of programming languages. In the case of C++, basics to know include virtual methods, virtual destructors, operator overloading, how templates work, correct syntax, the standard library, and more. Anything less, and a senior developer will likely get furious; they have a job to do, and that job isn't teaching the ins and outs of programming. With all that in mind, what's a minimum level of knowledge for a programming language for entry-level developers?
Classes, class inheritance, smart pointer, vector, operator overloading.
That should suffice as the starter pack. You can learn the rest in your job when the need comes.
....and water will likely get wet.
As a C++ hiring manager I like you to have a relevant degree; know C++-98 pitfalls to the level of Meyers, "Exceptional C++", "More Exceptional C++"; be aware of or know the Gang of Four Patterns. Familiarity with Sutter and Alexandrescu's writings are nice. Knowledge of Lakos and physical design (rate) is a big bonus. In a big project, even with good programmers, they usually make a mess out of the physical design. Some understanding of unit test and coverage is good too.
unique_ptr is normally preferred over shared_ptr -- the former is zero-overhead compared to a pointer, while the latter has a reference count associated with it which has to be incremented and decremented. If you know two or more things will be using the pointer and you don't want to have to worry about ownership semantics, shared_ptr makes a lot of sense. If you know only one will be using it, unique_ptr makes more sense.
You cannot turn off RAII (Resource Acquisition Is Initialization) in C++, since it is an idiom and not exactly a language feature. What you are talking about is problably RTTI (Run-Time Type Information). Both of these features have zero performance overhead if not used, so there is really no point in turning them off. Just don't use them in performance critical places.
* Objects passed by value which don't have a deep assignment copy constructor. // Bang! There goes another foot... maybe if we had GC...
* File scope objects using other file-scope objects - "Because VS2010 ensures instantiation order."
* Dependencies with no real reason; this is especially bad on Qt projects. Why use std::vector when you can use a QVector?
* const char *use_this_later = MyQstringObject.toStdString().c_str();
If someone is doing any of these, then they should be fixed at the code review stage. There's no reason to let any of these live. If someone insists on continuing, then let them find a new place of employment.
* You used copy semantics? You *meant* move semantics (This should never had made it into the standard).
* Overloaded functions - "myfunc (foo);" does something different to "myfunc (bar);", because hilariously foo and bar are different types
* Ditto for operators - "foo + bar" does something quite different to "bar + foo".
If there are differences in these behaviours, then, again, you're doing it wrong. "Foo + Bar" should always behave analagously to "bar + foo". There's barely a language around that gets away without overloaded functions, so failure to grasp that is a failing indeed. Move and copy semantics really only need to be understood by library writers. For everyone else, they basically just need to understand that it's ok to to return vectors by value.
* Other than "type var[size];" there is no primitive array type. Arrays are implemented in the library, not in the language like every other sane language.
So, other than an array type, there's no array type? What does that even mean? The whole strength of C++ is that things can be built into libraries rather than baked into the language. My container with feature Y is just as integrated into the language as the STL's vector, or a "type var[size].
I don't know who told you C++ was an object-oriented language. It's not -- ask Bjarne. It supports many different styles of programming, object-oriented being just one of many, but it is in no way object-oriented. You can write large code bases without using a single object.
Huh!? According to Stroustrup in "Design and Evolution of C++", C was certainly intended to be "C with a little extra". It was also designed to be C with a lot extra. He intentionally created the language so that C style code would still run just as fast as before. You could just take advantage of the nice things like function prototypes (remember when C++ first came into being was before ANSI C) and declaring for loop variables inside the loop, etc. You could begin to use the new features as you wanted.
Or, you could go full bore with objects, etc.
Thirty years of development later, we have today's C++.
"Almost every wise saying has an opposite one, no less wise, to balance it." - George Santayana