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

I would suggest the stl

[Ambassador Kosh]

There are many things you can use to improve your c++ code like std::vector. With that you store data contiguously in memory but you also don't have any manual memory management. No new, no delete, no malloc, no free.

For my high performance work I tend to use std::vector, BLAS and LAPACK and my programs usually have no manual memory management of any kind in them. Valgrind shows no memory leaks and the programs are very easy to read and work with.

If you want to do high performance c++ then learn OpenMP and MPI. If you want to do threading just use OpenMP since that makes it VASTLY easier to get threading correct. Add tasks with OpenMP along with their dependencies and you end up with a nice cross platform and very high performance code base if you have done your job correctly. If you need to scale to multiple nodes then use MPI between nodes.

Re:Error Handling

[Ambassador Kosh]

I may hate seeing it written that way also but that is also the current most common way to write it and that is what HR systems and their computer screening systems except. You are writing a resume for an HR person usually and if you want it t be seen by someone more important it has to get past them first. That means doing stuff that HR people understand.

There are many fights to take on in this world and others that are just not worth the effort to fight since the costs are so high compared to the benefits and this is one of those fights.

Re:Simple ...

[serviscope_minor]

Wow the smug condesention is strong in this one.

I for my part wrote an STL clone around 1993 when the STL was just a lab experiment at HP.

The hard bit about the STL is the whole concept of, well, concepts that Stepanov finally hammered out. The STL, especially 1993 era is not all that complex.

Well, iostreams and their interaction with locales is deeply fiddly and I'd steer clear of that. But the basic algorithms, you know, vector, list, set/ma/multiset/multimap, sort, heap, priority_queue and so on and so forth are not too bad.

Not to say it's not an achievement, but it's not enough to convince me that you're an uber-guru. I've written STL compatible containers, and STL like algorithms for things that weren't in there. Apart from quantity the principle is the same.

Perhaps you should read what I wrote: I have roughly 15 years consecutive C++ experience from 1989 till 2005, plus random 3 or 4 years over the last decade.

15 years experience, or 1 year of experience repeated 15 different times?

Given you've never seen code without new in it (as your other post claimed), I'm inclined to think the latter because you seem to be deeply ignorant of whole swathes of C++ style. In a lot of code, you never see new and delete. Everything is managed by containers. I work on computer vision systems, and you can get entire working, robust systems without a new anywhere in sight. The custom containers might have a new in, but that's---well, let me check the library I'm using---let's see there's 80 instances of new in 40k lines. Of those most are in old code from before TR1 gave us many standardised smart pointers, and others could easily be replaced with a std::vector (the code's not perfect, it's been hacked on for the last 15 years), some are strange, silly uses and the rest are to initialise now deprecated auto_ptr.

There's about one legit one which uses placement new and posix_memalign.

With spare time, I could make that one in 40k lines of code easily. In fact that's going to happen slowly as the library is being transitioned to C++14.

I find it terrifying that someone who pust themselves forward as a super C++ guru is splattering new so much all over the place. But you won't believe me because without knowing anything about me you've convinced yourself that you're superior.

Let's see what a real, certifiable C++ guru says:

http://www.informit.com/articl...

Bjarne doesn't like new/delete either. No offence, but I'll take his invention ans stewardship of the language over your 1 year of experience repeated 15 times.

I doubt you regularly find one here on /. who has significantly more C++ experience.

Out of interest, do you have any T-shirts with disparaging things written about n00bs on them? And are those slogans visible under the cheeto dust?

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: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: Knowing when not to

[evenmoreconfused]

Even though I believe I'm quite a good coder, when I read code from 5 years ago, I'm always surprised to realize that I can do better and simpler.

Whatever the state of your code is today, it will be a mess in a few years.

Yes. I find this to be the case too (I was a programmer in the seventies and eighties, and have been in programming management ever since).

So it begs the question "can one write code that one won't think is sub-optimal five years from now?". I've begun to suspect that one can't -- so just learn to accept it and move on.

What I try to get programmers to do is write code that is A) clear and simple and B) balanced in terms of development vs. maintenance time. I don't want programmers wasting time perfecting code that's not going even be looked at for years to come, nor do I want code that takes days to get into when attempting small fixes.

It's like building a house: if you follow the building standards, it's quick, safe, and any plumber or other trade can walk in later and quickly fix or modify things. If you do a bodge job it all has to be torn out and redone properly, or, if you create custom installations, it gets very expensive to create and especially to maintain.