Comparing the C++ Standard and Boost 333
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.'"
Boost Sucks (Score:2, Insightful)
There, I've said it. It's obscuratist beyond all reason and results in incomprehensible code of the type that any professional programmer should be ashamed of.
C-like C++ is the way to go (Score:5, Insightful)
I just cannot embrace the mess C++ became anymore. Life is too short to learn C++. Basically I'm using "C with classes" today, without STL, Boost or any of these aberrations.
Re:Boost Sucks (Score:5, Insightful)
Boost is sort of like CPAN for perl- its a repository of libraries you can pick and choose from. It has some really useful things in it and a lot of crap. Talking about how good/bad Boost is is pointless, from a code perspective. Talk about how well or not well it works as a repository.
Of course, that makes the linked article pointless too- programmers write libraries for a language faster than the standards committee updates it? No shit. If they didn't, we ought to be worried.
Re:C-like C++ is the way to go (Score:5, Insightful)
The container classes (list, map, vector, etc) in the STL are good enough to be worth using. And of course string. Going full out with functors, generic programming, etc does frequently make an unreadable mess, but no need to throw out the good parts with the bad.
I never liked the idea of C++0x11 (Score:4, Insightful)
We had decent (not perfect) C++ support. Now we go and fragment the industry by inventing a new standard. Code developed to the 0x11 standard won't work on legacy systems with legacy compilers.
Meanwhile boost and Qt worked around the C++ limitations without introducing any compiler differences. I think that was the right approach. True not all things could be delivered without messing with the compiler, but a good many were.
Now my only problem is that Qt (the leading C++ library aside from stl) and boost are not compatible. Boost has the more permissive license, but it is its own license, and boost additions can be under their own license. The Qt library is now LGPL (or commercial), and as of Qt5, Qt is divided into even smaller modules.
I hope the community does not fork again (C++ vs 0x11) with boost vs Qt. I cannot decide whose library should be adopted. But whatever comes to pass, I hope either Qt adopts boost or boost adopts Qt, to prevent further fracturing of C++ community.
Re:Bit stale (Score:5, Insightful)
I don't consider myself a "professional" programmer, though I've certainly programmed things that are used in my workplace, saved quite a lot of money for employers by doing so, and programmed things since I was a child on any number of languages. If I see a program and can't work out how it does what it does, I'm quite happy to tear it apart just to see how they did it, and even - when source isn't available and reverse-engineering isn't practical - re-create my own version to see if my hunches were right.
C++, to me, is just gibberish. I sat and read any number of books on how great OOP was and how C++ use these things and I have to admit, for many years, I was convinced. It was only when I got out of contrived examples and tried to understand another programmer's code that I realised that - actually - C++ just gets in the way. Boost even more so. I'm sure there is a way to make it lovely and I'm sure if you do it day in, day out and nothing else, that you get used to it and begin to see it - like reading music or anything else.
But a programming language is a LANGUAGE - something that facilitates communication. That's not *always* just between the computer and a human, but between two humans using computers, for instance. And there, C++ really falls down. I've seen projects that were created in C, built up in C, got famous in C and then converted to C++. I followed everything in them, even sending patches and hacking my own code into them, right up until they converted. And then they became a mess that I didn't like to touch, and certainly couldn't contribute patches to any more.
I get a lot of flak for that opinion, but I can write C99 code that does just about anything I ever want. I haven't yet thought "What this really needs is C++". I've even re-created object-oriented concepts in C99 and been perfectly happy with how they work and how to understand them.
And the fact is that a random bit of C99 code posted by a decent programmer - you can normally get the grasp of it quite quickly. A random bit of C++ code? You could be there forever checking overloaded operators and class declarations to see what the hell it actually does. Sure, you can obscure code in either language, but C++ seems to go out of its way to make even simple concepts obscure when expressed within it (don't even get me starting on templates).
I'm just not sure that the effort of "learning" C++ inside-out to the point where all that gibberish just becomes second-nature is actually worth it for the return, compared to just working a little harder on some basic C99 code to do the same things.
Re:Bit stale (Score:4, Insightful)
Re:Boost Sucks (Score:5, Insightful)
Boost has on the order of 100 libraries [boost.org] , each of which undergoes a peer review
CPAN allows anyone [cpan.org] to upload their own code and has on the order of ~120,000 libraries.
Boost is a lot less like cpan and more like the development branch of the next standard library.
Re:Bit stale (Score:4, Insightful)
The problem with your C99 comparison that, by comparison, a random bit of C99 code does trivial things described in great detail, whereas an equivalent bit of modern C++ code is able to execute orders of magnitude more business logic. Don't get me wrong: C99 is great for close-to-the-iron bit twiddling and severely resource constrained execution environments, but C++11 is able to offer equivalent performance, the ability to tackle complex problems and vastly greater expressiveness.
There is of course one major caveat: C++ requires more experience of the programmer to produce maintainable code. Otherwise, you are even more likely to end up with unmaintainable gibberish than you are in C99. But against poor programmers the gods themselves debug in vain.
Re:Boost Sucks (Score:0, Insightful)
Waaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa ;)
Boo fucking hoo. The rest of us in the real world need to get shit done, and libraries like jQuery are essentially imperative for writing modern web applications intended to function across browsers. Additionally, the average jQuery download per page is way less than 80KB as not all plugins are downloaded in any sane webapp.
Re:Boost Sucks (Score:5, Insightful)
It sounds like you're missing the significance of Boost. I cant think of any other thing like it, CPAN included. Yes, it's a collection of libraries. That's not the interesting part. There's a reason so many of the C++11 library additions were taken directly from it with little to no changes.
Most projects you'll find code to the standards of the one or two people making them. The good ones are fairly flexible, but many of them fulfill just the specific needs of those authors.
Boost lies somewhere between that typical project design and a standards body. Its review process demands high-quality standards-worthy code without taking years to debate on something before anyone actually writes any code. Once libraries actually get in, it serves as an incubator to find out what works and what doesn't. Because it is coded to such a high quality and people are actually using it, it gives the standards body a lot of data to work with in deciding what should be next for the language. That's what makes it special.
Re:Boost Sucks (Score:5, Insightful)
There, I've said it. It's obscuratist beyond all reason and results in incomprehensible code of the type that any professional programmer should be ashamed of.
Agree 100%.
Libraries are supposed to be understandable and easy to use. Boost just isn't. I don't know if the documentation or the design that's at fault but it always seemed totally opaque to me whenever I looked at it.
I could probably grok it if I invested enough time/effort, but what I get in return (eg. a reference counted pointer) never seemed worth that investment.
YMMV.
Re:I don't like boost (Score:5, Insightful)
Some of your requests will never happen, and with good reasons, I'll explain:
e) Fix the macro language so it is type safe
The macro language is not part of the c++ language. As far as I know, Bjarne would have loved to get rid of it entirely, but it was kept to help maximize C compatibility.
g) Deprecate and REMOVE that stupid 'short', 'long', 'double' crap from the language
Why? Sometimes the user wants to use types which are relative to the CPU word width, but don't want to be tied to a specific bit width. Remember, not everyone who codes in c++ uses an Intel CPU.
h) Provide PROPER 16-bit, 24-bit, and 32-bit characters
16/32 characters are fully supported in c++11, see char16_t and char32_t. I could be wrong, but I don't think I've seen a language which has 24-bit characters. It would likely be inefficient to support anyway since I'm not aware of any architectures which 24-bit access is properly aligned.
i) Fix the darn grammar so that compilers accept UNICODE source
Many compilers already do support UTF-8 in source code. But I do agree that this should just be standardized across the board.
j) Fix the darn grammar so that compilers RECOGNIZE identifiers WITH Unicode characters
Why? So you can have a function named () instead of pi()? This strikes me as something which would just make it harder to read.
k) Add a proper exponent operator
Won't and Can't do this efficiently. Not all CPUs have an intrinsic way to do exponention. This is specifically why it's a library function so it is obvious that it is potentially a non-trivial operation. Once again, not everyone uses an Intel CPU.
m) Add proper multiple return types
This would be nothing more than syntactic sugar. Why is using a struct such a big deal?
n) Fix all the times the spec says "undefined" or "implementation dependent". The point of a spec is to SPECIFY what the operations do, NOT to be ambiguous because in some idiotic universe 'char' is not exactly 8-bits.
NO. You will probably disagree, but this is part of the *strength* of both C and C++. By allowing something to be undefined or implementation dependent. The standard is allowing the compiler to choose the most efficient code to emit. If the standard were more specific in these places, we'd have a "one size fits all" solution which would be optimal for some architectures and very much sub-optimal for others. Better to let the compiler writers who know the arch best to decide these things.
q) Add a proper rotate-left and rotate-right bit shifts
See the answer to exponent operations. Simply put, not all CPUs have this. I would however welcome a standard library function for this like pow for exponents. Which the compiler could inline to a single instruction if the CPU supports it.
When is C++ going to add reflection support?
It probably won't because it's not well suited for how things work in the language. Here's (part of) the problem. With templates and optimizations, often there can be 100's of types created during compilation which are independent but get optimized away to literally nothing when finished. Should the compiler waste time and space generating reflection information for types which simply don't exist at runtime? Should the compiler emit reflection information for each and every template instantiation of std::vector that your program uses? You can't do one set of reflection's for each template, because different specializations can have different members! It spirals out of control really fast. Personally, I would not be apposed to an opt-in reflection system. You use some special syntax, let's say:
reflect class T { };
or something like that. Which would then add extra stuff to the std::typeinfo object associated with that type. So that way you could in theory do something like this:
typeof(T).methods(); to get a list of methods for T, IF you have opted in. But I don't think that will happen.
Where should warm and fuzzy really come from? (Score:4, Insightful)
You can get that same warm feeling by writing good code in C, assuming only you have the skill to do it. Furthermore, when it is useful and appropriate to step outside the paradigms that C++ would force on you, but you can choose to use in C, you can. You'll understand why you did it, what you saved or cost yourself by doing it, and it won't be buried underneath some ridiculous, time-and-space wasting get/set layer, etc.
Not saying C++ is bad. Far from it. But I am saying that C is fully capable of supporting strong, highly correct programming, and that if C++ restrictions (or those of any other language) are the source of your feeling of having "done it" correctly... it's very likely there's more basic programming landscape for you to explore.
Re:C-like C++ is the way to go (Score:2, Insightful)
I just cannot embrace the mess C++ became anymore. Life is too short to learn C++. Basically I'm using "C with classes" today, without STL, Boost or any of these aberrations.
Out of curiosity, is this desire for self-inflicted misery part of a larger BDSM kinda deal or is it due to willful ignorance of standard practices and idioms that have been well entrenched in the C++ community for the better part of a decade now?
Re:I don't like boost (Score:5, Insightful)
g) Deprecate and REMOVE that stupid 'short', 'long', 'double' crap from the language
Why? Sometimes the user wants to use types which are relative to the CPU word width, but don't want to be tied to a specific bit width. Remember, not everyone who codes in c++ uses an Intel CPU.
I think if you asked people how big a short or long is, 99% would answer it's a fixed size and of the 1% that in theory knows it's CPU-dependent 99% of them don't use it to create any intentionally different behavior on different CPUs. The 0,01% that really use this could have something like a set of typedefs in a platform configuration file, while the other 99,99% won't get bitten in the ass by flawed assumptions that a short will always be 16 bit. Nobody but C/C++ has this ambiguity in their most basic units that are used in pretty much every example, pretty much all other languages, databases etc. have found it sane to define them exactly. Sorry, but this is a horrible part of C/C++ even if you happen to like it.
Re:C is the way to go (Score:4, Insightful)
Ok, but on the other hand you can also end up with things like GTK.
You mean like, an object model that provides dynamic signal-slot binding, properties, introspection, and bindings to really productive high level languages such as JavaScript and Vala? Count me in favor.
Re:I don't like boost (Score:5, Insightful)
I think the reason for omission is simply that the operators are nothing more than syntactic sugar. Anyone that needs those operations can write them quickly without putting much thought into it.
Both the GP and you are wrong about this. Hardware support for exponentiation is completely irrelevant to it being a built-in operator rather than a function call.
FORTRAN, famously, has some extremely efficient tricks for implementing exponentiation by small integer exponents (up to 7, if memory serves) that are independent of MPU support. They are handled by the compiler. Why C/C++ doesn't have this is beyond me, and writing these things efficiently for a given architecture is non-trivial and better handled by the people porting the compiler than application developers.
Re:C-like C++ is the way to go (Score:4, Insightful)
I don't know what practical problem does std::string solve, because sure as heck it doesn't provide most of what you actually need to use strings in real life applications. Qt's QString and the associated codec infrastructure is pretty much what you need. std::string is a solution to a problem that nobody has. If all you need is to pass around safe arrays of characters, then std::vector does it for you, duh. std::string is a safe wrapper for C strings, and that's the whole problem: modern software has outgrown C strings two decades ago.
Re:c# is (c++)++ (Score:2, Insightful)
That's why so many commercial 3D engines are implemented in Java, not C++, right?
Re:C is the way to go (Score:3, Insightful)
What I can do, however, is point out that people who write in C++ don't write those things; they use the language's own constructs, and so they don't know what's going on -- only that it is.
Most C++ programmers I know, myself included, know very well about what's going on in the code that compiler generates. Don't assume that just because something is automated, people who use it are unaware of how it works.
Re:C-like C++ is the way to go (Score:4, Insightful)
However, the std::string classes were designed too soon, and a lot of the member functions are clumsy and should have been offered as generic stl algorithms. It's probably best to consider them deprecated.