nexos wrote:
...if a programmer can't write memory management code or a quicksort, who's to say they will be able to reason through problems that certainly will crop up in programming.
There is nothing intrinsically "more instructive" in practicing programmer skills on memory management or quicksort implementations than, for example, implementing a graph algorithm using Boost.Graph.
With the difference that the latter is part of what will likely be actually expected of a C++ programmer in the field, while the former very, very much
is not, because it is reimplementing the wheel, solving solved problems
again.
nexos wrote:
If they don't understand pointers and their perils, or integer overflows, stack overflows, heap overflows, etc, or how sorting works, or all of the "low-level" things, and they use libraries instead, it might make it easier in the short term. Eventually, they will have a problem they can't solve with a library, and they will write ineffeicent . insecure code. All because they learned the easy way...
To the contrary. You still haven't understood it:
Manual memory management has no place in modern C++. None. Period. It's a leftover, a piece of backward compatibility for when you have to deal with C APIs, and if you think "new" faster than "#include <memory>", "pointer" faster than "reference", then you are a liability in a C++ team, and I hope QA will show you the error of your ways before you break something important.
The basis on which to build is
not the C subset of C++. It's not even C++98, that ship has long sailed, left in the dust of the distant past by C++11, which really changed the way we should look at the language. C++17 is really the bare minimum you should accept today, and your training of newcomers should reflect that.
You don't teach C# newcomers C first, either. I hope.
nexos wrote:
Remember, easy often leads to suboptimal results.
I have worked with C++ for over 20 years. 95% of all the problems I ever encountered -- and that estimate is very much on the safe side -- were due to people who learned C first, and stopped learning C++ halfway through because they figured they could "make do" with what they already knew. What resulted was a hodgepodge of C constructs sprinkled with some std::string that leaked and broke and was a pain to maintain.
And usually performed pretty poorly when compared to the C++ replacement, too. But even when the C code squeezed a couple of percent out of the platform, that was never worth the burden of resource leaks and unmaintainable spaghetti code.
Trust me, the very best thing that could happen, from a quality perspective, is a C++ programmer who has learned about pointers and "the nitty gritty" only when he was forced to do so by an actual assignment. I would
love to see C++ programmers coming out of training who would actually understand that a C array[] and an Object * ptr = new ... and char * are basically big red neon signs saying "error to be found around here".
nexos wrote:
I can say for myself that knowing C and writing good C programs makes you able to write efficient programs and think on your feet (which is very important as a programmer!).
Learning
any language makes you able to write efficient programs
in that language. When you start learning a new language, you might be able to carry over
work ethics (like, be disciplined about code structure, make good commits, document your work). But you really have to learn the new language
as a new language. C++ is not a superset of C, and has not been since last millennium. It is a language of its very own, with a somewhat unfortunately easy to access backward compatibility layer.
C is not the entry door to C++. It's like crawling in through the sewers and expecting to find your place at the dinner table.
----
PS:
Kate Gregory agrees.