A Brief Look at C++0x

NOTE: This is a restored version from this archive.

C++ inventor Bjarne Stroustrup describes the next version of the C++ standard.

For all the coolness that this next version is supposed to introduce (no, it’s not the name), nothing is said about what seems to me the biggest issue of the C/C++ world, namely the diversity of build standards.

C++ is a pretty tough language with a zillion built-in ways to shoot yourself in the foot. Writing C++ is a tad less scary and a little more user friendly than juggling with chainsaws, in that the error messages do not involve bandaid or ER procedures. But that’s all. This being said, a C++ compiler is an extremely powerful tool which, given the right set of safety measures (courtesy of Mr Scott Meyers, need I say this) can help you produce some of the most blazingly fast code ever seen on earth. Template metaprogramming is not a feature of C++, it’s THE feature. Have a look at Boost or STXXL to see what I mean.

BUT. The whole process of running the compiler and linking with third party libraries is a mess. In the Java or .NET world, integrating a third party library is pretty easy : you take the JAR file or Assembly DLL, put it in a place where your compiler can find it, and bam, you’re done. Nowadays, building a Java program is done the same way everywhere, provided you use ANT which is a de facto standard.

In the C/C++ world, you have Makefiles with their 70s coding style (a perfect case for the nastiness of significant whitespace), configure scripts, static and dynamic libraries in different, mutually incompatible formats. One compiler suite won’t sometimes accept libraries built with another compiler suite. You have configure scripts which are only there to try to build a kind of standard environment to develop against, unless of course the platform you’re trying to build your program doesn’t support them. You have different build tools like make, nmake or even bjam for Boost. Each time a new version of a compiler is released, the build configuration files must adapt or wither and die. Library developers have to support a hundred different build environment, which frankly is rarely what they were expecting to do when writing their library.

Python tries (and succeeds) in saving the developer some time with its setup system (the distutils module), but unfortunately binaries built from Python 2.3 under MSVC 6 aren’t compatible with those built under MSVC 7.1. If you can’t afford an old license of MSVC 6, you can try using the MinGW suite but that’s a brand new set of kung-fu moves to learn. But you won’t ever, never succeed in building a Python 2.3 extension in MSVC 7.1 or a Python 2.4 extension with MSVC 6. Maybe. I don’t know. I can’t bear it anymore.

At the end of the day, I don’t know about you, but I for one get a lot more headaches struggling with the build mess than tackling with C++ delicacies. C and C++ are more inherently portable than the build environment that surround them. How’s that for a paradox ? The complex is portable where the supposedly simple is not.

Unfortunately the only solution is once again to reinvent the wheel and try to force the whole world to drink the new Koolaid. I’m not convinced this has a chance to succeed… But that’s really sad to see the C++ baby disposed with the dirty bath water that the build system can be.