Knowing C++ Beyond a Beginner Level

Nerval's Lobster writes: C++ is not an easy language to master, but many people are able to work in it just fine without being a 'guru' or anything along those lines. That being said, what separates C++ beginners from those with 'intermediate' skills, or even masters? According to this Dice article, it comes down to knowledge of several things, including copy constructors, virtual functions, how to handle memory leaks, the intricacies of casting, Lambda functions for C++11, (safe) exception handling and much more. All that being said, is there one particular thing or point that separates learners from masters?

Comments

Knowing when not to

[perpenso]

What separates C++ beginners from those with 'intermediate' skills, or even masters?

Knowing when not to use templates, virtualization, [insert favorite c++ function here], etc.

Basically knowing enough about programming and problem solving with a particular language to tell a need from a want. Needing to use some language feature vs wanting to use some language feature. And being mature enough to stick to needs rather than indulge wants.

Or to state things differently ... all the features have a time and place, and its probably not all the time and in every place.

Re:Knowing when not to

[PolygamousRanchKid]

I agree with your comment entirely. I would only like to add that a true C++ Master writes code that a C++ Novice can understand.

Time to get philosophical. Tomorrow, you could get run over by a bus. Take a wander around your Cubical Town. Are there enough folks there who could take over ownership of your code?

You can do some really cool things with C++. But if other folks cannot understand them, well it's best not to do it. Cool C++ features are like nuclear weapons: very powerful, but think about the consequences of using them . . .

Re:Knowing when not to

[eulernet]

You are thinking like a manager.
As a programmer, I don't want to be replaced easily, and I don't care about my work when I'll die, or even when I quit my company.
I have no problem to share my knowledge with my co-workers, but why should I write code for somebody who'll replace me ?

Also, unless you write frameworks, I doubt very much that your code will be reused.
It will probably be rewritten.

Re: Knowing when not to

[Anonymous Coward]

but why should I write code for somebody who'll replace me ?

Because future you will replace present you. If you need to revisit code years later to fix a bug or add a feature, you want to be able to pick it up straight away, rather than try to figure out the mess you left behind.

Re:Knowing when not to

[TheRaven64]

making the code run faster qualifies if it's not running fast enough yet

And then only if backed up by realistic macrobenchmarks. There are a lot of things in C++ that have interesting performance characteristics (templates allow more inlining, so make microbenchmarks faster but can cause you to run out of i-cache and make the whole program slower, virtual functions prevent inlining unless the compiler can do devirtualisation, but are actually slightly faster to call than cross-library calls via a PLT if they're not inlined). Generally, algorithmic improvements will make a bigger difference than any language feature. The main reason for using templates should be to eliminate copy-and-paste coding, not to improve performance.

Re:Knowing when not to

[TheRaven64]

If you can't be replaced, then you can't be promoted. Do you really want to be maintaining the same program for the rest of your life? And do you want to have a reference that says 'no one can understand this guy's code' when you leave for the next job?

Re:Knowing when not to

[serviscope_minor]

This is complete and utter tosh.

No one I know who does high performance code (such as numerics, real time computer vision, that sort of thing) uses anything but C++, especially for new projects. There is nothing out there that combines the speed and expressivity of C++, and when you know performance is going to be a factor at some point, C++ is the only choice.

Frankly for a lot of scientific and numerics style coding, I often reach for C++ initially even when performance isn't required since it often maps on to those problem domains better than any other languages I've used.

Oh and then there's the embedded world, where your choices are C and C++. Plenty of people use C++, since it like C scales all the way down to the 8 bitters like Atmel.

Re:Knowing when not to

[serviscope_minor]

If you need really high performance you don't use most of the C++ features anyway, and end up basically writing straight C.

Nope nope nope nope nope nope nope nope nope.

That is far, far, far away from correct.

Check out something like Eigen or TooN (a somewhat more obscure library which is used in the vision world for things like PTAM). They are very far from C++. The code written down in an editor reads more like maths. There's no explict loops, no explicit memory allocation. They're both high performance libraries used in challenging applications (seriously download and run PTAM, it's amazing).

They're also fully templated so you can stick in an AD type instead of a normal number and get derivatives out automatically with no extra effort.

Writing high performance C++ is nothing like writing high performance C. It's much better. All the messy C details of allocation and etc simply vanish, leaving clean, nice looking code which is straightforward to read, write and debug.

Or another example from today for me. I need to find the best N (lowest cost) elements during some wort of complex search. It's easy. Just create a priority_queue<pair<double, int>> where the double is the cost and the int is the index of the object.

Then about 3 lines of logic keeps the pqueue updated with the best N so far.

All the irrelevant logic of how a queue works is witten and debugged by someone else and hidden from me without ever losing either performance or type safety. For bonus points, if I find I'm searching very small things and memory allocation becomes a penalty, I can switch the entire thing to stack allocation with almost no effort at all!

Re:Knowing when not to

[eulernet]

If you can't be replaced, then you can't be promoted.

It depends on the kind of promotion.
Not everybody dreams to become a project manager.

Do you really want to be maintaining the same program for the rest of your life?

Not really, but if the pay is good and the job is nice, why not ?
Personally, I have a life outside of my work, so I don't really mind.

And do you want to have a reference that says 'no one can understand this guy's code' when you leave for the next job?

That's the least of my worries !
Do you think that the guy who will take your place won't hate you, even if your code is beautiful ?
Do you believe that your company will not fire you if there are problems ?
If the company doesn't care about me, why should I be faithful ?

Finally, I have a personal question: why do you work ?
Is it to receive aknowledgment, money, fame, self-esteem, or something else ?

Re:Knowing when not to

[Actually, I do RTFA]

You are thinking like a manager...I don't care about my work when I'll die, or even when I quit my company.

I'm both a programmer and a manager, so I can probably weigh in. I do care about what happens to your work when you leave the company. And part of my job is to make sure that your code is usable.

why should I write code for somebody who'll replace me ?

Because code is an asset that you are being paid to create. And if your code is not maintainable, it's not much of an asset; it's worth far less to me. So, if I notice our code is a fuck storm of uncommented overly complex verbiage, I'm not letting you work on anything important. So, maybe you get to work on small one-offs (really career enhancing), maybe I just fire you. But certainly I don't expect to allow you to keep extending your tentacles..

The reason you say "most of your code will be rewritten" is because it sounds like your code is poor. Why would I pay asset-level prices for stuff with a shelf-life of a year?

Re: Knowing when not to

[crgrace]

Wow. You're right. It's only been four hours and your comment is already a mess.

Error Handling

[oggiejnr]

I've always considered error handling to be the most important thing when it comes to knowing a language beyond the beginner level. Every language has it's own idiomatic ways from RAII in C++, finally/using in Java to the myriad of ways of handling return codes in C. It is also frequently undertaught in most programming language courses.

It is for this reason I despise seeing C/C++ on CVs. It implies that you don't have a strong foundation in either language as idiomatic code is so different between the two. By all means list them as two separate languages, but be willing to demonstrate sound knowledge of both, not the bastardised, resource leaking hybrid I see so often when the term C/C++ is invoked.

It's not about knowing, it's about understanding

[rippeltippel]

Since C++ is the language of choice when you need performance (along with C and - sometimes - assembly), to write good code it's essential to understand what each line of code does to the machine (memory, registers, ...) and if/how instructions can be optimized by the compiler.

This level of awareness is generally not required to be proficient in other languages, but in my experience it's what makes the difference between newbies and pros, at least in the areas where C++ is used for a good reason.

Said that, it can be useful to understand as much as possible of any language and C++ can provide strong foundations in that sense, as this short article points out: http://www.forbes.com/sites/qu....

Masters don't play with Dice

[MightyDrunken]

One of the defining feature of a non-beginner programmers is that they don't read Dice articles to find out anything about computer languages.

Who else stopped reading at "this dice article"?

[Qbertino]

Just asking. :-)

Re:Given how C++ is taught.

[Rei]

"Smart pointers" are great -- if you don't care about performance (in which case, why are you not using Java?).

Since when does Java's performance even come close to C++'s in benchmarks? C++ performance is generally very close to that of C's, and in some cases exceeds it (example: qsort vs. std::sort - C++'s use of templating allows for inlining of the sort function code)

Smart pointers have very, very little overhead. The worst is std::shared_ptr, and it's still only adding a reference counter, and that's only used on pointer copy and deletion. And if you have a use case that requires std::shared pointer as your smart pointer of choice, then this is counting that you'd have to be doing anyway in some form or another.

  From the benchmarks I've seen, most people see about an additional 5%-ish overhead in debug mode with std::shared_ptr vs. raw pointers in pointer-heavy code. In a release build there's generally no measurable effect (the difference being, in debug mode it can't inline the dereferences).

Re:which part

[MiskatonicAcademic]

Scientific (matlab but faster): who cares, you just want the answer, not the software, right?

Not always true. Sure, there is plenty of well-motivated ad-hoc coding in scientific research. However, we sometimes have supercomputers working for months to generate the answer. Even with well-written software this could mean many core-years of number crunching. Without good high-performing software we would not get the answer at all. Developing good scientific software takes time and effort too, but if the software can be used over and over to efficiently solve >1000 problems (for instance, the GROMACS papers have been cited by users ~15,000 times), then the time invested can be very good use of taxpayer money. C++ is not a bad choice for such software in that it enables very good performance and decent maintainability.

Re:Masters know their limitations.

[UnknownSoldier]

This 100%. C++ has become a clusterfuck of over-engineering and I say that as someone who has worked on a C++ compiler.

* /Oblg. Comedy: Hitler on C++

When you have even committee members admit they only use a sub-set then you know the language is too big.

The C++ committee recognizes there are many problems with C++ iostreams but nothing is being done towards performance and type safety.

The committee would rather argue over the rare case of multi-dispatch / multi-methods then fix core issues.

* http://www.stroustrup.com/mult...

Crap like long long, "long double", etc. should have been deprecated in year X, and removed in year X+5. Are they going to add "long long long" someday?? Having types like "double" in 2015 is just retarded -- replace it with "float64_t", and the fore mentioned long double with the clear "float80_t". Bandaging the problem like int_fast32_t doesn't solve anything. How many fucking integers types does the compiler need to throw at us?? short, long, long long, int, long int, int_fast32_t, int_least32_t, etc. and I'm not even talking about MS's hacks of __int32, __int64, etc. Simplify the dam language already!!! Set year 2020 as the date when these barbaric types are deprecated, and year 2030 when they are removed.

Modules have been in a constant state of on-again-off-again for over 10 years:

* First mention N2073 (Sept.2006)
* Revived N4047 (May 2014)
* 2nd draft N4214 (Oct. 2014)
* 3rd draft N4465 (April 2015)
* Wording N4466 (April 2015)

The pre-processor is STILL broken. One would expect #define token operation to work for ALL user-defined tokens. i.e. This isn't rocket science, just a basic Search-and-Replace:

#define @(func) printf("%s\n",func)
 
void foo()
{
  @(__func__);
}
 
// Hell, even this should work
#define @ printf("LOL. Your pre-processor is broken. HA-HA!\n" )

There are no standard pre-processor macros for function names as a string. GCC has the excellent __func__ which Microsoft finally got around to implementing C99 N2340 in Visual Studio 2015!

The C++ committee failed to learn the first lesson about design:

* "Needlessly complexity is a symptom of bad design."

Or paraphrased from Einstein:

* "Things should be as simple as possible, but no simpler"

Re:Experts...

[superwiz]

Just think about it! (TM) A function gets automatically executed just because you leave scope. Doesn't matter how you leave it. Forget that it's a destructor. It's a function which gets called automatically without anyone writing any code to call it. Show me how to do that in C. And that's the fundamental difference between the 2 languages. The rest is syntactic sugar.

Re:Experts...

[Smerta]

I've made the exact same argument to co-workers at many firms... namespaces (e.g. Timer_Init()), virtual functions (tables of function pointers), etc. can be approximated / kludged together... but automatically invoking a function at the right place (destructor and, let's face it, the constructor is pretty handy too) is something that has to be baked into the language, and C++ has it. I work in safety-critical systems, and knowing that I can't leave a function with interrupts disabled, I can't forget to close this socket, etc. is incredibly comforting.

I'll quote Bjarne Stroustrup here:

"Just that closing brace. Here is where all the ‘magic’ happens in C++. Variables get destroyed, memory gets released, locks get freed, files get closed, names from outside the closed scope regain their meaning, etc. This is where C++ most significantly differs from other languages. It is interesting to see how destructors -- an invention (together with constructors) from the first week or so of C++ -- have increased in importance over the years. So many of the modern and most effective C++ techniques critically depend on them"