Examining C++ 11Posted: November 7, 2012
I was recently looking at doing some more C/C++ coding, and was wandering through the interwebs and came across this succinct explanation of what’s in C++ 11:
From this very brief description of the key features, I came to the conclusion that there’s not much there for me really. There are some good things like ‘auto’, which allows you to let the compiler infer the type of something rather than being explicit. Not news to those who have been using dynamic languages for the past few years.
Then there’s Lambda expressions. Ditto on the dynamic language comment.
A refresh of the various libraries, yah, ok, thanks. Probably one of the most important additions is the nullptr type. Phew!! After so many years, there finally a formal definition of null, such that there’s no confusion between “NULL” and ‘0’.
Still existant is the confusion one gets from trying to figure out the exact semantics of ++foo vs foo++, depending on the context.
The saddest thing of all is that there is no garbage collection, or auto reference counting. There is some support for smarter pointers, so it’s a little easier to not shoot yourself in the foot.
As an evolution of the C/C++ franchise goes, this seems as good an evolutionary step as any. I personally would have voted for garbage collection over async support, but that’s just me.
What about the current version compared to a modern dynamic language such as LuaJIT? Lua, with its terse language, does a lot of things, and has very few standard libraries to speak of. All it really has going for it is the garbage collector, and a very small footprint. And herein lies the interesting inflection point. Who is the modern programmer? Back when C was in its infancy, the “programmer” was typically an electrical engineer, and possibly an “IT” professional, but a fairly low level hacker. Certainly there were no script kiddies, and everyone at the time probably had gone through flipping switches on a PDP 10, if not at least using IBM punch cards to enter their programs in a batch to get their reams of line printed output.
Where this stuff really does matter is when your down programming micro controllers, and other tiny devices. In those cases, you’re just barely a step above assembly language, and this is where the original intention of C really shines. By the same token though, C++ does not shine, because it’s too big and bloated. All the libraries, the complexity, and niceties really don’t serve you well when you’re running in a constrained 64K environment.
So, I’m conflicted. At one point in my career, I was a C++ expert. It served me well. Then I left it behind for things like C#. I don’t really see the value in getting deeply immersed in the intricacies of the current wave of C++. It lacks sufficient memory management, and I’ve found over the years, this is one of the most important aspects of a runtime environment.
I know that many people will think “but real programmers program in C++”, and all I can say is, real programmers use whatever tools are necessary and appropriate for a particular job. Real programmers write code that is easy to read and maintain, and that might mean writing in any number of languages over time.
I like the evolution of the C++ language. I’m happy to not ride that particular train into the future, if I don’t have to.