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.'"

Re:I never liked the idea of C++0x11

[Anonymous Coward]

> 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++ is a disaster

[Anonymous Coward]

Has anyone here tried reading the standard? It's unintelligible.

Has anyone here tried reading C++ code? Like the standard, a lot of it is unintelligible. To C++'s credit, this isn't a problem with the language itself, per se. It's a problem with substandard software engineers.

I write C++ professionally. I like C++ because I am adept at expressing myself in it. I can build useful things with it quicker than I could with C. But every once in a while, I'll get reminded that I don't know C++ as well as I thought I did. C++ has a myriad of pitfalls that are difficult to understand until you get first-hand experience being bitten in the ass by them. And often times, when it happens to me, I think to myself, "this is so incredibly fucking stupid."

C is the way to go

[fyngyrz]

Finally, my personal experience with matter is unambiguous - professionally written high level C++ code is easier to maintain, has fewer bugs and is simply less verbose and more to the point then procedural, lower level C-style code.

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.

Re:I don't like boost

[UnknownSoldier]

>> a) Add a PROPER 'alias' and a PROPER 'type-def'
>Define "PROPER"

First, there are times:
a) When you _need_ strict type safety
b) When you _don't_ need strict type safety

Second, read up on C++ mangling/demangling because if you don't understand that you won't understand my point.
http://en.wikipedia.org/wiki/Name_mangling [wikipedia.org]

Agner is a guru of assembly language and has written a great document; specifically the section "The need for standardization"
http://www.agner.org/optimize/calling_conventions.pdf [agner.org]

Here is the usage case where we want BOTH (a) and (b):

typedef int Foo; // same as "#define Foo int" (an alt. syntax could be: 'alias Foo = int')
newtype int Bar; // We want a NEW type, one that is NOT aliases, that differs by NAME only, NOT functionality.
// There is no current way to do this C++ unless you abuse templates.

void AllowFoo( Foo foo ); // c++filt -n _Z8AllowFooi
void AllowFoo( int i ); // Oh look, this semantically equivalent as above; it is redundant/harmless in C++, since there is only 1 mangled function due to aliases not being new types

// We want the compiler to make a SEMANTIC difference between the following two functions -- they should be mangled _differently_:
void ReqBar( int i ) { ... } // We want this overloaded function so we can catch accidental calls to it OR not even provide it at all !!
void ReqBar( Bar bar ) { ... } // ILLEGAL in C++ due to lack of proper non-alias support -- it is mangled the same as: void ReqBar(int)

int i = 1;
Foo f = 2;
Bar b = Bar(3);

AllowFoo( i ); // OK typeof( i ) = typeof( int ) == int
AllowFoo( f ); // OK typeof( f ) = typeof( Foo ) == int
AllowFoo( b ); // Should be an error, but can't tell C++ this is a different type, the C/C++ typedef gives us "nothing"

ReqBar( i ); // C++ can't block this func at compile-time
ReqBar( f ); // C++ can't block this func at compile-time: typeof( f ) = typeof( Foo ) = int != typeof( Bar ) = Bar
ReqBar( b ); // typeof( b ); // typeof Bar != int

Does this make sense?

At least C++ treats SomeVoidFunc() and SomeVoidFunc(void) as being mangled the same now.

Don't even get me started on how C++ ignores the return type for the mangling! There are times when it would be _extremely_ handy to call a different function based on the return type. Sadly C++ lacks this.

>> c) STANDARDIZE the pragmas
>You've missed the point of pragmas.

And you've missed the pain and agony of having to support multiple compilers because the idiotic compiler writers were too SHORT SIGHTED to understand customers do NOT want proprietary vender lock-in having to support yet-another-compiler.

Do you understand the purpose of having a _common_ way to specify structure alignment and packing??

e.g. How you disable the compiler warning about "unused variables" in Microsoft Visual Studio, GCC/G++, Intel C/C++ Compiler, etc?

We standardized the width of train tracks for a REASON.

We standardized the traffic lights even though everyone drives different vehicles from 2 wheels, 3, wheels, 18+ wheels, etc.

As programmers we are forced to solve the same dam problem over and over in everyone's "pet syntax". When is this insanity going to stop??

>> d) STANDARDIZE the error messages
> Compilers differ. This might not be possible.

I'm not interested in political excuses. I

Re:c# is (c++)++

[Pino Grigio]

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.