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.'"
instead of verbose vagueness need to have lists of comparisons between standard libraries and boost. is this author practicing to be paid by the word?
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.
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.
I still have more fans than freaks. WTF is wrong with you people?
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.
> 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.
Boost has on the order of 100 libraries , each of which undergoes a peer review
CPAN allows anyone 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.
"the day I walked away from C++, Boost and MFC"
I have considered this in detail, and I think I may have spotted a problem with your argument. It can perhaps best be explained with the following example:
"the day I walked away from peanut butter, jelly, and shit sandwiches"
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.
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.
No sig today...
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.
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.
For example, try to create a random number from 0 to 1.
This is almost always an error. Your poor use of terminology on this matter tells me that you've probably implemented the error.
It is nearly always the case that when you think that you need a value in the range [0.0 to 1.0], that what you more precisely need is a value in the range [0.0 to ((double) RAND_MAX / (RAND_MAX + 1))]. Otherwise any sort of binning done with this value (such as selecting a random element from an array) will have non-uniform distribution.
You will thank me some day.
"His name was James Damore."
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.
Live today, because you never know what tomorrow brings
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.
Blasphemy is a human right. Blasphemophobia kills.