Slashdot Mirror
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?
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.
... all the features have a time and place, and its probably not all the time and in every place.
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
:eyerolls:
We're all learners. But anyone with more than a passing familiarity with C++ already knows everything in that puff piece of a Dice article.
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.
You should certainly be familiar with the syntax.
You should almost never see a new, and never a delete in normal code (rare exceptions for guru library writers only). If you do, you're almost certainly making life hard for yourself.
Another thing is programming with concepts. These aren't part of the language yet, but are part of the culture, part of the design of the STL and hopefully will make it into the language. Things having the same "concept" are types where the operation of the semantics are the same.
This is like a field in mathemetics: you have addition, multiplication, subtraction and division (well, really the additive and multiplicative inverses). If you get the proofs right, they'll work on any field. This is why you can muliply with a modular FFT.
For example, ints, floats, std::complex all obey the same concept, that of a number. There are more, such as automatic differentiation types provided by expernal libraries.
Another example is vectors in "metric spaces". A VP-tree is like binary search, but instead of working on an array of numbers, it works on a multidimensonal metric space of vectors. Normal 3D vectors in Euclidian space is a metric space (distances obey the triangle inequality), but interestingly so are bit vectors and hamming distance and even strings and edit distance. The underlying algorithm of a VP tree relies on several semantics. You need to be able to measure distances and update some lower and upper bounds. That is all.
The art of concepts is writing the algorithm using the abstract interface of the concept upon which it operates. This has several nice properties. Firstly, you use nothing more than the concept. If you use an operation which isn't part of the concept, it's almost certainly a bug. Secondly the algorithms are much clearer because they don't mix in the implemtation of one specific instance of a concept (e.g. building edit distance right into your VP tree) with the underlying algorithm. And finally, once you've done that you get genericism for free. Stick a template around the class and you have a working, debugged algorithm which works on everything it could work on.
This is how the STL works. For instance std::sort requires two concepts. The range spanned by the iterators passed to it must work with radom access and you must be able to compare the elements with <. Given that it can sort anything.
A good stage to get to as a C++ programmer is to write code like that, not necessarily even because you need the genericism but it forces you to separate the underlying abstract algorithm from the concrete specific datatype it is operating on this time. Doing so has many benefits.
SJW n. One who posts facts.
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....
There is no single one thing to look for, because what you really want is EXPERIENCE with C++ programming and that encompasses a lot of things. But if you want an easy test to see if somebody has got enough experience, get some code sample that produces a lot of different warnings at compilation time and have them explain what the warnings mean and how one should get rid of them.
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.
Computer modeling for biotech drug manufacturing is HARD!
I thought I was a guru level C++ programmer (I have been programming C++ for around 2 decades) but even I am constantly finding out about new things I didn't know existed.
I recommend this link: http://programmers.stackexchan...
There is someone asking whether 8 lines of slightly clumsy looking code can be replaced with something better. The beginner wouldn't ask that question and wouldn't know an answer. The master would say "your code is just fine", because it is actually straightforward, easy to understand, easy to check for correctness. The first answer on stackexchange adds two arrays, one 20 line function, and a few lines of function calls resulting in code that is hard to understand and verify.
Now where C++ is a bit unfortunate is the fact that once you leave beginner level and think you know it all, you have unlimited potential to create code that nobody can understand.
so, you claim you know:
...
int a = 13;
In which register a is residing, supposing we are on an ARM? Or suppose we are in an 68k? Or suppose we are on an x86?
You are just an idiot!
I don't claim i know, I claim that I understand: something that you're clearly neither willing nor capable of doing, as your question and offensive language suggest.
Have a nice day!
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.
The most dangerous drug
Memory objects that clean themselves up after they go out of scope are the devil's work. The devil, I say!
What about the Ant People? They owe us money.
Just asking. :-)
We suffer more in our imagination than in reality. - Seneca
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?
SJW n. One who posts facts.
C++ lets you have just as much control over the code as C. The key difference is that it doesn't make you memory manage your objects every time, when 99.99% doing that is irrelevant toward performance and only serves as a common route to introduce bugs.
What about the Ant People? They owe us money.
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.
I shouldn't rise to the bait but, oh well.
There is no single job interview where I don't have to correct the interviewer about false assumptions of how certain stuff works in C++ ...
Any competent professional will be aware that C++ is a language so vast and with so many obscure corners that there will be corners that they would need to check to be sure and may well get wrong in an interview situation. However...
What is called in which order? Constructor? Assignment operator? A potential cast from bla to s? Or, the copy constructor?
And why the funk am I supposed to know that?
The reason this question would probably asked at interview is that there is a candidate who claims to be expert at C++ who is making statements about obscure corners of the language that are probably wrong but an interviewer doesn't want to get into an argument about it. So instead they'll ask something that any reasonably competent C++ programmer would be aware of (because this syntax is a legacy of C and doesn't do what a naive C++ programmer might assume)
It's also interesting that the really smart C++ programmers are usually quite self-effacing. They probably won't comment or will say something like "Oh, I thought it was B but I'm not sure" if they think something the interviewer said is wrong. They certainly won't be aggressive about interviewer mistakes (although any sensible programmer won't take a job where the interviewers are making to many basic mistakes in the language)
God said, "div D = rho, div B = 0, curl E = -@B/@t, curl H = J + @D/@t," and there was light.
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:
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"
This 100%. C++ has become a clusterfuck of over-engineering
Nope. It's mostly hampered by the need to be backwards compatible. The committee know full well if they make serious breaking changes, then the C++ world will split into two distinct languages. Many, many people won't adopt the new one and the vendors will continue to support them because there's money there.
It's a blessing and a curse. The curse it it's hard to do anything but add features. The blessing is my code I debugged 13 years ago still works.
The committee would rather argue over the rare case of multi-dispatch / multi-methods then fix core issues.
You're basically being an arse. You're picking out one rather speculative paper designed to help C++ stay modern a ways in the future (and somehow labelling this as a bad thing) and yet knowingly ignoring the many papers on fixing core issues.
Modules have been in a constant state of on-again-off-again for over 10 years:
Yeah they should just slap in some module crap and if it's wrong, just rip it out and replace it. Who cares about getting things right and not breaking working code, eh? They learned their lesson very hard with export templates and are keen to not have to learn the same lesson again.
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!
So you submitted a proposal, right? Or do you expect other people working for free to magically know your personal problems from your whining on slashdot?
SJW n. One who posts facts.
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.
Any guest worker system is indistinguishable from indentured servitude.
Congrats, you clearly have the bigger C++ e-penis in this case.
That's probably the most common type of logical phallusy.
SJW n. One who posts facts.
And, once again, Nerval's Lobster gets a piece accepted which is little more than a thinly veiled reason to link to one of the endless stream of lame stories about "how much toilet paper do you really need" articles.
Have you guys become so blatant with the click-whoring to Dice you have designated people who write pithy sounding summaries for repetitive and lame articles to drive to Dice.com?
Because there are suspicious amount of lame "how much do you" articles submitted by this one poster, and all linking back to Dice.com. And never a mention that Dice.com is the parent company and is shamelessly shilling their own crap.
Sorry guys, but you're becoming really obvious with this.
Lost at C:>. Found at C.
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"
Well, it's a compiler extension, but GCC supplies the __cleanup__ attribute which essentially allows arbitrary destructor functions in C.
Mastery of the language is one thing, mastery of the tools another...
-- Mike