Examining C++ 11

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:

http://blog.smartbear.com/software-quality/bid/167271/The-Biggest-Changes-in-C-11-and-Why-You-Should-Care

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.

C has acted as the basis for many a language since.  Simple control loops, assignment statements, and the like.  But the programmer population has changed, the demographics have shifted.  With Visicalc, suddenly office workers were ‘coding’, along with visual basic, then html, and nowadays JavaScript.  Many modern day “programmers” doesn’t know anything about the PDP 10, how memory is laid out, what the Operating system is really doing down there, or anything else about the machine they’re programming for.  Having very low level access that C provides, just isn’t as relevant.

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.

It seems more prudent to stay immersed in basic C, because that’s what is universal from lowest level microcontrollers to mainframes, and stay connected to a dynamic language, such as javascript, or LuaJIT.

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.

Advertisements

One Comment on “Examining C++ 11”

  1. On my first job as a game developer, I had to port with two other programmers thhe metal gear solid game from playstation to pc. I was avid C++ programmer, and before that Turbo/Borland Pascal. Once we got the Konami source code, and I saw how beautiful C can be. There was a custom made oop, basically each struct that participates in the “oo” simply included the parent structure. The “constructors” were each done using int argc/char*argv way, and lots of them were directly initialized from the scripting language, whcich was a mini form of tcl (I realized this years later)
    And although there were only japanese comments, and no easy/cheap way to translate them (this was in the years of 1999-2000), the code was so simple to understand, that there was no need.
    That was my turning point, later when I joined Treyarch, the code for the nhl2k2/3, spideman, etc. was C++ heavy, so much that linking times were killing us. Coders on the UI part were using templates for the menu enums, and since back then the compilers/linkers were not so smart, this introduced a big duplication in the executable (I started digging myself). In later projects I came to detest e ridiculously long lines, filled with singleton calls, the way we were serializing stl structures to disk (it was a streaming game), and overall the hard way to read anything.
    The biggest monstorsity was a template library, 200k, that required such an enourmous concetration to use it, and even though release times were faster, the debug times fell like 6x times for things like vector/matrix multiplications, since almost all math operations were overloaded opearators, and in debug these were function calls (forceinline was either not eorking for us, or we did not used it)
    And later when I saw boost, I thought there is a problem.
    We chose google protobuf overr thrift lately, simply because boost times would’ve killed our compile/link times, and people had to sync to thousand of files.
    There is good C++ – I like The Juce library, gdiplus, even some STL, also for UI systems it fits better.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s