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?

Comments

Answer

[s.petry]

NONE! Find a real language! *ducks*

Re:Answer

[lgw]

NONE! Find a real language! *ducks*

For non-ducks, the most important things to know about C++ aren't list in the summery: RAII and shared_ptr<T>

C++ is not C. C++ written like C tends to be crap code - just an overly complex and distracting language for that coding style. If C++ is the right tool for the job, you need to be using a coding style very similar to C# and Java: throwing exception when errors are encountered, writing exception-safe code all the time, returning from functions in the middle, and never, ever, worrying about cleaning up at the bottom of a function what you allocate at the top.

If all of that sounds wrong to you, congrats, you're a C coder, and there's nothing wrong with that. Good C code is good code. But C++ is designed to be used with "scoped objects", that is, every object cleans itself up when you exit scope, so you really have to internalize the tools for that, and that mindset.

Re:Answer

[Spazmania]

C++ is not C. C++ written like C tends to be crap code - just an overly complex and distracting language for that coding style. If C++ is the right tool for the job, you need to be using a coding style very similar to C# and Java

That's a bit of a problem, because when you program in C++ the same way you'd program in Java, you lose the efficiency and simplicity of C without gaining the clean design of Java. Java is superior to C++ in almost every reasonable use of C++ *except* the ones which call for programming in C but with, you know, a little bit plus.

If all of that sounds wrong to you, congrats, you're a C coder

I resemble that remark.

Re:Answer

[rjh]

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.

Re:Answer

[TheRealMindChild]

I don't know how to respond because this whole post is bullshit.

If you are using C++ as such a high level language as Java/C#, you may as well use them because you threw away some of the most useful/valuable parts. Also, Exceptions are EXCEPTIONAL and should be treated as such... only expected to be thrown when something exceptional happens, not as a means of flow control.

Re:Answer

[lgw]

. Java is superior to C++ in almost every reasonable use of C++ *except* the ones which call for programming in C

That's just, like, your opinion man!

Seriously, though, C++ was never intended to be "C with a little extra", but instead a Java-like (but native code) language with backwards compatibility with existing C code. You can see that throughout Stroustrup's writings, including how he says C++ should be taught (start with std::vector and std::string - don't even teach arrays and char* until people have the basics internalized).

IMO, C++ properly written is a better Java - no worries about resource cleanup (Well, now Java has try-with-resources, so it's not so bad), vastly less boilerplate, a great standard algorithms library, and so on. Java's advantage is in its easy learning curve, and standard cross-platform libraries, which led to a vast selection of open-source tools. If the C++ standard had included more cross-platform system libraries earlier, Java might not have the library advantage. While C++ finally has threading in the STL, it's missing so much other systems-level stuff. But at least I can have a freaking unsigned int in C++ if I want to!

Re:Answer

[ron_ivi]

unique_ptr ... shared_ptr

LOL at how C++ gets new smart pointers every couple years.

It's like they're trolling their own users with their:

• classes are kinda like structs, so you can use 'typedef struct ... *' for classes and 'void *' for generic functions (Everything from CFront in 83 through ARM in 99)
• no! 'void *' pointers are broken! use 'auto_ptr' instead (C++03)
• no! 'auto_ptr' is broken! use 'shared_ptr' instead (C++07/TR1)
• no! 'shared_ptr' is broken!(for most use cases) use
• 'boost::scoped_ptr' instead (non-standard, but more useful than the standard's shared_ptr)
• no! 'boost::scoped_ptr' is broken! use 'std::unique_ptr const' instead (C++11)
• no! 'std::unique_ptr const' is fugly! use "auto" and hope C++14's "return type deduction" will guess a safe type and hope C++17's "new rules for auto deduction" won't break stuff (C++14)

crap.

How the heck can people take an "object oriented" language seriously when it takes literally 30 years (1983 to 2014) for them to come up with a non broken way of making a reference to an object....

... and in the end they give it a syntax like "std::unique_ptr const".

W.T.F.

Re:Answer

[rjh]

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.

Re:Answer

[brausch]

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++.

Re:Answer

[slimjim8094]

(I work at Google and use C++ there, but what follows is my opinion)

What precisely don't you like about the C++ style guide? (This is almost identical to the internal guide)

- It is true that exceptions are verboten, but honestly it's not particularly limiting. Java gets exceptions right - something is truly "impossible" (in a crash-the-program you-have-a-logic-error sense) and thus you don't need to handle it, or else it's "expected" like an I/O issue and the language forces you to do something with it - either try/catch, or declaring that you're potentially passing it along. C++ doesn't have any such enforcement, which makes it very hard to reason about what a function may throw at you. You rely on everybody in the entire call hierarchy doing the right thing. Reminiscing about my Java days, the lack of exceptions does make some things somewhat more cumbersome to deal with - having to explicitly return a status object, for instance, to deal with plausible-but-atypical cases. But the Google guide is fairly apologetic in this area and basically says "sure, we'd use it if we had a brand-new codebase, but we don't..." and the reasons that follow for why exceptions are hard to integrate into a truly enormous codebase seem sound to me. What do you disagree with about this reasoning?

- There is certainly no rule about "allocate at the top, clean up at the bottom, never return from the middle". In fact, with unique_ptr and the like, there's even less reason to do those kind of things than there's ever been. The local variable part of the style guide actually explicitly encourages as-close-as-possible declaration, and the rest of the style guide is quite gung-ho about unique_ptr (we actually had an internal class for a long time that was sufficiently identical to unique_ptr that they were able to replace all uses and remove the custom type in just a few months). I can find no reference to any sort of prescription about the location of return statements.

- The standard libraries have actually been moving away from exceptions, haven't they? C++11 introduced 'noexcept' and added it to a bunch of methods, and the specs for a lot of other ones guarantee that the only exceptions are from the allocator (e.g. std::bad_alloc). To be clear there is no prohibition against *using* code (especially the standard library) that may throw exceptions.

In a nutshell the style guide is, in order, "be readable" followed by "be consistent". It is hilariously easy to write unreadable, bug-prone C++ code. Nobody cares if your code is perfect and correct, they care if the next guy along can modify or use it correctly and it is useful to have a style guide to make some of the more hard to reason about things impossible. How many different bits of code could the statement 'a = b;' potentially execute? (It's a lot - copy constructor, operator=, operator Foo(), etc.) The style guide limits it to just a few things you might have to consider, so that when you use some code someone wrote 6 years ago there's not so much to look at. C++ has references and pointers, which is great, but at least with pointers there's a hint that you might have "spooky action at a distance" so the guide mandates their use for out-params which seems perfectly reasonable since it's basically arbitrary which to use - and in practice, it's a really handy hint to have when you're reading. Unless you're passing an address, you know your copy can't be modified. IMO, way more readable.

If you've really been hanging up on recruiters because you object to the style guide, it is probably worthwhile to actually ensure that your understanding of it is correct and up to date. It has changed in recent years as C++11 has become better understood and it is fair to say that it is far more liberal to things like lambdas, template metaprogramming, operator overloading, copyable classes, etc - than it was a few years ago.

None. Go meta.

[Anonymous Coward]

Knowing C++ shouldn't matter. Demonstrating that you can quickly master and use any language should.

Re:None. Go meta.

[Anonymous Coward]

This is surprisingly accurate. No amount of programming language knowledge will help you write a good program if you can't design the software from a practical level, upwards. What do you want the computer to do? What exact steps do you want it to take? Good, now translate that into $programming_language. That last part is actually the easiest part of software engineering.

Re:None. Go meta.

[war4peace]

Pseudocode.
http://en.wikipedia.org/wiki/P...

Also Drakon charts.
http://en.wikipedia.org/wiki/D...

I actually was taught DRAKON charts (a variation of it) in high school back in '96. It tremendously helped me in more ways than strictly programming (which I never embraced). My teacher used to call it pseudocode back then, although Pseudocode is different.
At the time, generating a high level overview of the processes in DRAKON before building any code was mandatory, and it sped up code generation because you always knew what the next steps would be.

How to read f*ucked up code

[mveloso]

The biggest skill in C++ is how to read code that's got templates, generics, overloaded operators, and custom keywords.

"What do you mean they overloaded '+' to merge objects?"

"This doesn't look like C++, it looks like some foreign language."

"Oh, we reversed the meaning of + and - because the senior guy thought that the original semantics were incorrect. But only for some objects."

Which C++?

[Anonymous Coward]

Is it abort maintaining some old code which tends to be more like C with use of class instead of strict,
Or is it C++14 which is a much more modern language?

"How do you monetize Slashdot?"

[93 Escort Wagon]

That's a question Dice posed to several middle managers recently. "We paid a lot of money for this tech property, but we have absolutely no idea how to use it", said one Dice higher up who requested anonymity. "Seriously - help us out here! There are over three million Slashdot subscribers, but none of them will click on an ad!", he lamented. "And they won't come over to dice.com and discuss these stories we keep cross-posting! We don't want to just be a second-rate job board forever..."

"a senior developer will likely get furious"

[gatfirls]

....and water will likely get wet.

For C++, there is no standard answer

[swillden]

For C++ there is no standard answer, because every C++ shop uses a different subset of the language. There are probably a few things that all of them have in common, but it's unreasonable to expect that any entry level C++ programmer can be productive without support from senior programmers while they learn the local ropes. Even experienced C++ programmers will need a little time to get up to speed on the local style guidelines.

C++ doesn't have an extensive set of standard libraries, either, which means that every shop has its own set. So senior programmers have to expect that new people are going to spend a lot of time getting up to speed on those.

Finally, I think the question is fundamentally bad, because it implies a misguided expectation of immediate productivity. That's a common expectation (hope?) throughout much of the industry, but unless you're hiring contractors for six-month jobs, its stupid. What matters in the longer run isn't what your new hires know coming in the door, it's how well they learn, and think. Because whatever they know coming in is invariably inadequate in both short and long term. One of the things I found very refreshing when I joined Google is that they don't much care what you know in terms of languages, libraries and tool sets. It's assumed that capable people will learn what they need to when they need to learn it, and that any new project involves some ramp-up time before people are productive. On the other hand, given a little time to get up to speed capable people will become very productive. Much more so than the less capable person who happened to know the right set of things when hired.

Code reviews

[JustNiz]

Your best bet is to find out if the place you intend to work for does regular peer reviews of code as a part of their process, and if not either stay clear or get an agreement that they will code review your stuff at least for a few months until you know the ropes.
Code reviews of your efforts, if done properly, are the best way I know of becoming effective quickly.

As a hiring manager

[Anonymous Coward]

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.

Re:As a hiring manager

[janoc]

And I do hope that you offer a senior developer wages as well for these sort of requirements. The OP was talking entry level job.

People requiring these sort of skills for an entry level job are the true reason for the perceived "lack of IT talent" - unreasonable expectations and entry level pay.

The Correct Answer

[Anonymous Coward]

If Bjarne Stroustrup doesn't come to you for advice, you aren't qualified for an entry level C++ position.

How else can we prove that there are not enough qualified applicants and need more H1-Bs?

Encounter

[SuperKendall]

Don't think he was a duck. From the fact that he was about to give us a list of real languages but then failed to do so, I can only assume the last "ducks" was him exclaiming at being overwhelmed by a wave of ducks, that subsequently ate him.

Yes, I am quite sure the real problem is he was a victim of.... fowl play.