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.'"
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.
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.
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.
Slashdot's rate-of-post filter: Preventing you from posting too many great ideas at once.
If you wait for another decade to come up with an update to the standard, you'll find even more independent libraries and implementations. People need to solve their problems now, they can't wait for somebody else to decide what to include into a standard. Example: a native string object must exist in a language of 21st century, so must a list, a set and a map.
You can't handle the truth.
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.
Metaphorically speaking, are you concerned about a future where everyone can assemble a house with prefabricated parts, but only the smallest minority know how to fabricate the parts? I fear as more high-level programming language jobs are created as entry level positions people become increasingly reliant on an entire layer of software they don't understand. Does that mean someone should have to know how to write a video driver to write a video game? Well, maybe. I don't know.
Help fight poverty: Punch a poor person.
"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"
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.
boost.function, boost.asio, boost.optional, boost.foreach, boost.shared_ptr, boost.ptr_container
start using those libraries (at a minimum), and C++ coding starts to become as easy as scripting. Of course, you'd have to learn C++ first.
In the course of every project, it will become necessary to shoot the scientists and begin production.
Fair warning: I program but am not a "programmer". That is to say, I have educational background in object oriented programming, STL constructs, and design patterns, but I'm not a software engineer so it doesn't get used much. What does get used is C, because in embedded systems it come sup quite a bit.
The issue I have with any argument about which tool is better is that the problems solved by C++ don't come up much for a large swath of problems, but they come up constantly for others. If the object-oriented version of your design would ultimately involve one uber-object, you shouldn't take an object oriented approach. If you're going to managing a lot of moving pieces in real time, you probably do want an object-oriented approach. If you want to tightly specify behavior at compile time so you know it will behave as expected at runtime, then templates are a good tool for bolting together well-tested parts to get a reliable new part. (When you're working with templated classes and methods, what you're really writing is a specification. You're not doing immediate work, but when work comes up you can put very tight bounds on how it is done. It's a different mindset than many other aspects of coding.)
Complaining about the lack of shiny new features in C/C++ is a lot like complaining that your MCU doesn't support an assembly STRCAT command, or that your Ethernet cable is bad about recognizing lost data and requesting it be re-sent. That's not their job. That's a higher-level problem for higher up in the stack. Trying to force features against type like duck logic only weakens the tool. When it rains don't ask your hammer to be an umbrella, use the hammer to build a house. Yes, that means you will often use non-C/C++ language to roll out an application. It also means that you need appreciate when those non-C/C++ languages create more trouble than going back to a rock-solid bit of C code would. Use the right tool for the job.
, or whatever, which is much shorter, less code for your to screw up and almost certainly bug free from being used/checked by thousands of others.
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.
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.
I've fallen off your lawn, and I can't get up.
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."
q) Add a proper rotate-left and rotate-right bit shifts
See the answer to exponent operations. Simply put, not all CPUs have this.
Do you know why not? This seems like such a simple operation.
Give me Classic Slashdot or give me death!
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
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.
C11 introduced Generic Selection which allows type control in macros. Too bad C++ diverged so much from C.
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.
b) a darn STANDARD _Binary_ API so I don't have to worry about which _compiler_ AND _platform_ was used,
I'm not quite sure what you mean here. Do you mean generate compiler/platform independent code (some IR like bytecode/LLIR)? Or do you mean ntoh/hton and the like?
h) Provide PROPER 16-bit, 24-bit, and 32-bit characters
i) Fix the darn grammar so that compilers accept UNICODE source
j) Fix the darn grammar so that compilers RECOGNIZE identifiers WITH Unicode characters
Should both be fixed with C++11. Except 24-bit characters, which I've never heard of before.
k) Add a proper exponent operator
l) Add a proper wedge operator, along with inner and outer product operators
Seem rather special-cased here.
m) Add proper multiple return types
You can do this by returning a std::pair, a std::tuple, or a structure you build. However, I don't believe there is an easy syntactic way to split a pair/tuple into multiple local variables.
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.
Never going to happen. Most of those "undefined/implementation dependent" items are features, and compilers take advantage of them to optimize code. It does make some quirky edge cases, but makes a lot of code optimization techniques in use today possible.
When is C++ going to automatic garbage collection WITH the ability to tell the garbage system how many milliseconds you are allowed to use (inclusive from ZERO.)
Do you know a system that does this max time? Because it sounds ridiculously difficult, and would lead to cases where a program would have to fail because it has no memory yet is not allowed to do a full garbage sweep/reclaim.
The problem with that C++ is not that you can't write simple code, but is that the languages makes it easy to write verbose bloated code.
I actually don't believe this is the problem with C++ - you can write verbose, bloated code in most languages. The problem I see is that C++ was made to be as strict a superset of C as possible, and inherited an audience who want full control of things like object size, and memory allocation/deallocation behavior. Because of this, generialized code requires way more knobs to be tweaked than you expect, and templates have evolved to be a hacked-together functional programming language to determine optimal operation. In order to generate an optimal, generic library you have to make the code itself incredibly difficult to maintain.
That's why so many commercial 3D engines are implemented in Java, not C++, right?
m) Add proper multiple return types
This would be nothing more than syntactic sugar. Why is using a struct such a big deal?
It's been done the C++ way: add the generic tool, and natural uses flow freely.
e.g.:
tuple foo() ... ...
{
return make_tuple(1, 2, 3);
}
int a, b;
float f;
tie(a, b, f) = foo();
And with move constructors, it's efficient too!
SJW n. One who posts facts.
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.