Slashdot Mirror
Comparing the C++ Standard and Boost
Nerval's Lobster writes "The one and only Jeff Cogswell is back with an article exploring an issue important to anyone who works with C++. It's been two years since the ISO C++ committee approved the final draft of the newest C++ standard; now that time has passed, he writes, 'we can go back and look at some issues that have affected the language (indeed, ever since the first international standard in 1998) and compare its final result and product to a popular C++ library called Boost.' A lot of development groups have adopted the use of Boost, and still others are considering whether to embrace it: that makes a discussion (and comparison) of its features worthwhile. 'The Standards Committee took some eight years to fight over what should be in the standard, and the compiler vendors had to wait for all that to get ironed out before they could publish an implementation of the Standard Library,' he writes. 'But meanwhile the actual C++ community was moving forward on its own, building better things such as Boost.'"
> Now my only problem is that Qt (the leading C++ library aside from stl) and boost are not compatible.
You write as if you know what you're talking about, but this is flat-out wrong.
Certainly there are duplicated ways of doing things (improved filesystem support immediately springs to mind), but I've worked on lots of commercial code that uses both libraries, and I've seen similar elsewhere. Generally speaking, using Qt for GUI and other system-type abstractions, and boost for lower-level things such as multi-dimensional arrays, geometry, testing (even smart pointers back in the day). I've written boost AND Qt based code today, for the same project. There is no reason not to use both in any given project.
C code doesn't have to be procedural. You can implement classes and objects and what's more, you can actually understand how they work when you do. You can create just about anything you want (not everything, but very near.) You'll know what you are writing. You won't be including incredibly overweight code that bloats your app and slows it down. You can manage memory intelligently, you can construct very maintainable code, and you can be quite concise about it.
What you're running into, I suspect, is programmers that aren't experts in either C or OO. They know how to use the bits of OO that C++ "cans" for them, but if you told them to build such things... C++, like any HLL, has its place holding the hands of mediocre programmers, and also in empowering truly excellent programmers. But C is enormously capable and from my personal experience, it's hugely more maintainable, less verbose, and more to the point than C++ simply by virtue of the fact that the language space is much smaller -- only as large as it actually needs to be, with very few exceptions. A true object can be built in C without any of the cruft or "mommy" limits; it can be highly efficient in terms of both memory used and execution time. It won't end up being megabytes just to get a basic UI going.
The amount of "stuff" a programmer needs to know about a language gets in the way of the amount of "stuff" that same programmer needs to know about programming techniques in general and the specific task(s) at hand.
Every once in a while, I have to write in C++. I'm pretty good at it -- experts in C tend to have a good basis to add C++ concepts on top of. I even enjoy it. But contrary to your experience, I have found that most C++ code I have to deal with from others is very bad from the POV of maintainability, bugs (and they get a lot more obscure) and in being much more verbose (just a typical C++ header file makes that point rather well, without even getting into code.)
The worst thing I run into is the assumption on the part of OS documents that you will be writing in C++; pretty soon, you have to capitulate and get the C++ written, just so you can interface with the bloody system. All of a sudden, you're pulling in huge chunks of code you never heard of and have no interest in, and you have a form of the classic many-megabyte "hello whirled" program. Ugh.
I've fallen off your lawn, and I can't get up.
Is this a joke? You're making a real-time flight simulator in Java instead of C++ because your actual *rendering* is hardware accelerated and threads are easier in Java? You do realise that the unit of parallism on your graphics card is the *warp* (a bunch of pixels), not the driver, don't you? It doesn't matter how many threads you throw at the problem, the driver will mutex your concurrent calls to hell and it won't be any quicker.
Worse, you have no fine control over cache line efficiency in Java, which you do in C++, so it's probable your multiple threads will give the appearance of maxing your cores, but those cores will actually be sitting waiting on a cache line most of the time. I've seen a "multi-threaded solution" running on 6 cores that was only 1.5 faster than a single core solution because of this. If you want performance, C++ gives you the tools to make your code performant. Java abstracts all of that stuff away so you have no control over it. This is why C++ isn't going to die any time soon. Developers at the bleeding performance edge need it too much.