The proposed new standard for the C++ programming language, C++0x, has reached feature completeness. “This is ‘it’, feature-complete C++0x, including the major feature of ‘concepts’ which had its own extensive set of papers for language and library extensions (if you get the impression that concepts is a big feature, well, it is indeed easily the biggest addition we made in C++0x).”
I don’t think many people realize that, but this is huge news! Thanks to Thom for picking it up, I would have missed it otherwise.
With C++0x, C++ is more than ever playing the “dual language” card, being at the same time a very high level language (OO and generic programming) and still allowing very precise control of the emitted assembly instructions.
C++0x in particular allows more than ever to force as much as possible of the logic to be unfolded at compile-time rather than at runtime — such is the aim of the new “constant expressions” and the many improvements on templates. This makes generic programming much more powerful and pleasant — and lambda expressions and template typedefs are also huge in this respect, will allow to remove many dummy classes from one’s code. Meanwhile, the runtime aspects also get more controllable, with rvalue references…
C++0x is so far ahead of other languages in its own category, that is in the “high level multi paradigm languages while keeping full control of lowlevel aspects” category, that it’s not even funny!
Also know as HLMPLWKFCOLA
Far too many drink that COLA
Well the doc is going to be a long read but right away I can see the Threads section is not going to excite me one iota. If I want to program with concurrency across 4 or a 100 processors, this ain’t gonna do it. Nor does the .net or Java world do it either.
I think the real problem with C++ is that it is now an over dressed dinasour pretending that not much has changed in processors since C was originally developed for the PDP family. With 4 or hundreds of cores on a chip (not from Intel yet), and with the huge unpredictability of memory opcodes it is losing any relevance.
I have in mind a hybrid language that keeps close to minimalist C/C++ roots but borrows a concurency model from hardware languages like Verilog, but that means having a runtime scheduler or event wheel in there too.
The emperor isn’t naked, he is wearing all of his wardrobe at once. I am also reminded of that Algol68 monster that killed of Algol60 but led to the more manageable Algol W or Pascal.
C++ is a language. I love it, I use it every single day, but it’s still a language.
It’s not their responsibility to understand threads, this should be on libraries, not on the default syntax, IMHO.
You would like XC from Xmos.com I suppose. You’d even like the founder no doubt, transputer_guy!
C++ doesn’t natively support synchronization primitives. Ok, so now you whine.
I ask you this, though: what would you have C++ compiler writers do when the underlying hardware/OS doesn’t support some particular type of primitive natively? Have them write something completely new that needs to be run as some sort of kernel module or a driver?
Any threading primitives that aren’t truly…primitive… tend to lock a computer programming language down to a single OS or a subset of OS platforms: this is NOT the goal of the C++ standards body, as the C++ language has as one of its design goals that of being something that can be used to write things like an OS, or, for that matter, just write down to hardware very directly in an embedded system where there’s no real OS to speak of, but just ISR’s and a processing loop. As it is, C++ already has a fairly large runtime library that needs to be taken along with every application built: this may be linked in statically, or linked in dynamically. By making the language larger and less OS-independent as you would have it do, you’d end up making it less and less capable of fulfilling its design goals and target usage.
If you want languages with built-in threading primitives built-in to the language itself, you need to be willing to put up and go and implement a new language from the start with that in mind, or you need to just accept such things as user libraries, so that not all poor saps have to carry along excess baggage when they don’t need it. After all, while a large portion of the human population may be completely unaware of it, the number of CPUs used by machines people think of as any sort of personal computer is dwarfed by the number of processors in embedded applications that need such low-level languages as C/C++. C++ is complex enough as a language as it was, and as it is becoming, and is very powerful, too: there’s no overriding (pardon the pun!) need to overload things even more by going out of your way to make it bigger when such things can more practically (don’t take along excess overhead if not needed) do it in external libraries.
While you might be right that adding full support for threading and synchronization might be too much in some cases, C++ doesn’t do enough in other cases.
Here’s a fairly long explanation about what makes it possible (and legal) for a C++ compiler to generate code that will make it impossible to use threading at all in your programs.
http://www.aristeia.com/Papers/DDJ_Jul_Aug_2004_revised.pdf
Somewhere in between ignoring it completely and trying to make everyone happy is probably needed.
Right tool for the right job. For concurrency, the right tool just happens to be called “Erlang”.
But I won’t argue with anyone over the somewhat strange syntax of Erlang. But it sure does work.
That’s a pretty broad statement.
I’ve done programming with threads in C++, Java and even Python. Some of it could have been done in Erlang and other things I wouldn’t dream of doing in Erlang.
If I concurrency was only about getting the best performance out of your machine at any cost, then you might be right, but there are lots of situations where it’s just not worth it to use a tool like Erlang.
That’s a pretty broad statement.
Yes, indeed. I did of course not mean the obvious; attempting to write the next Crytek engine in Erlang just to be able to peak all your cores, and then let it borrow some from your friends as your machine just isn’t cutting it. For some things, there simply is no replacement for C++. The same goes for Erlang.
*Yawn*, call me when game are written in Erlang..
Erlang in an UP is slow (roughly half the speed of C/C++), so a part of Erlang’s scalability is “wasted” in catching with UP performance .. when it scales!
I remember a benchmark in which Erlang had IO limitation issue where the performance was much worse than C/C++ and where Erlang *didn’t* scale.
So yes Erlang has some strong points in concurrency (it’s syntax suck I agree) but it’s hardly the magical cure you make it..
Thank you for posting the link to that very interesting and informative article.
Yes, it’s true: C/C++ does tend to force you to go outside of the language strictly in order to ensure in order execution at the lowest levels. This isn’t a really huge problem in most cases in practice, if you’re not unwilling to work outside of truly portable code.
Having read through that article and seeing what it states, the simplest solution to enhancing C/C++ that I could see that would solve things most portably without screwing up the syntax would be this sort of solution:
void Example()
{
synchronize
{
instruction;
instruction;
instruction;
}
}
In this sort of syntax, everything inside the {} would be sequentially ordered, and the compiler would emit whatever CPU instructions are necessary to tell the CPU “Don’t DO OOE!” and then you wouldn’t have any issues with it being non-portable, and you also wouldn’t have it favor one processor over another. Also, in most real world conditions, such synchronize{} blocks would be very small and localized.
I would be in favor of extending the language in just this way, to this extent: anything more would likely start causing needless bloat for what’s supposed to be useful a systems programming language. Of course, there’s no way I can readily see to make a C/C++ compiler completely portable while also allowing full access to the absolutely lowest level of hardware (exact register access) but that’s not something any other language seems to be able to do portably, either.
Perhaps this sort of thing will be considered for the next standards body.
What ever happened to the KISS (keep it simple stupid) principle?
Hey, at least we still have languages working hard to achieve the opposite: simplicity
It took almost 10 years for the 1998 spec to reach a resonable level of support from available compilers.
Will this take as long?
probably.
Hopefully not as long as before. The Visual C++ 2010 technical preview already has some C++0x features such as lambda functions and type inferencing.
This is my meal ticket to retirement, working as a contractor clearing up the messes that people will create in this language. Thank you so much Bjarne and if you ever come to Australia, let me know and I’ll treat you to dinner at the restaurant of your choosing. It’s the least I can do in return.
Good news for C++ development. Finally some useful standardized cross platform types.
The only downside I see is that the new standard will be almost 100% compatible with the standard C++98. Thus you don’t need to update your code to compile so alotta crap code and styles can still be written if developers are not educated and use the new easier features.
On the plus side it makes for an easer break when one does occur. Compiler vendors can just say “C++0x” compatible only…
Some cool things that stand out to me:
1.
for (vector<int>::const_iterator itr = myvec.begin(); itr != myvec.end(); ++itr)
Can now be expressed as:
for (auto itr = myvec.begin(); itr != myvec.end(); ++itr)
2.
Much better compiler errors especially for the standard template libraries.
3.
Concepts sounds like a better expression of Templates.
4.
nullptr explicit null pointer keyword
5.
FULL cross platform support for strings! UTF-8, UTF-16, and UTF-32.
char has now been modified to be both at least the size necessary to store an eight-bit coding of UTF-8 and large enough to contain any member of the compiler’s basic execution character set. It was previously defined as only the latter. char16_t, char32_t deliver support for the other encodings. Thus for string literals we have:
—-
u8″I’m a UTF-8 string.”
u”This is a UTF-16 string.”
U”This is a UTF-32 string.”
—–
Thankfully you can also insert Unicode codepoints into strings in case you don’t want to type in the character themselves or as in the case of RTF text keep the text file UTF-8.
—-
u8″This is a Unicode Character: \u2018.”
u”This is a bigger Unicode Character: \u2018.”
U”This is a Unicode Character: \u2018.”
—-
6.
Multi-Threading! I am unsure what they have done here but it seems there may be a std::thread class now.
7.
unsigned long long and signed long long can now be expressed as uint64, int64_t
8.
Hash table types:
unordered_set, unordered_multiset, unordered_map, unordered_multimap
with insert(), erase(), begin(), and end() functions.
9.
Regular expressions class basic_regex now available!
10.
General-purpose smart pointers:
shared_ptr, weak_ptr, unique_ptr replaces auto_ptr
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2798.pdf
For 1., you could have done this even in regular c++:
#include<boost/foreach.hpp>
//…
BOOST_FOREACH(const int& i, myVec){ … }
And regular expressions were part of boost, too.
By the time they get it formalized I think its safe to say it will be C++201X
I haven’t followed C++ closely since college. My current employer is still using C90.
Despite its limitations good old C is a breath of fresh air compared to the more verbose OO descendents.
I think if there were anythig I would change, it would be a disambiguation of *, &, and ->. Programmers hate pointers in large part because of this particulary inelegant feature of C.
OO is overrated. Function templates, on the other hand… if I could just have templates and operator overloading with my structs….
C++ appeals to junior programmers who think they are gods because of how powerful and hackerish it makes you feel. People with a bit more experience realize that doing things like condensing 50 lines into one line, no matter how cool it is, is a horrible idea 99% of the time.
Good C++ is basically good C with a small, sparing amount of the “++ bits”.
Hell yeah. It’s like the Beatles of programming languages. Sure, its not bad, and even good in some ways, but not the be all and end all.
Good thing you did not write C++ appeals only to junior programmers…., because otherwise I would have to disagree vehemently. I work now for about 10 years as a programmer (mostly C/C++ in the areas of scientific number crunching and embedded programming) and found C++ in my junior years rather difficult to both pick up and work with. But nowadays, thanks to compiler vendors catching up in terms of performance and standard compilance, thanks to frameworks like boost, blitz++, STL, etc. and (last but not least) thanks to my better knowledge of the language and its in and outs, I *really* enjoy working with C++. Not beacuse I feel 1337 or ueber hackerish, but because I have a language at my disposal that may not be the best choice for any problem set, but is – if you know what and how to do it – a good choice for most fields of application. Which btw. is no excuse for not knowing other approaches, languages, etc. .
My last two projects this year were both from the embedded and data acquisition space. I had to work with four “C++” SDKs from the various vendors of our hardware (specialised motion sensors / IMU’s, steering controll units, environmental sensor packs, etc.). None of them were in a shape that I would consider to represent “good C++” although three of them were in essence pure C with some homeopathic sprinkles of C++.
Resources were handled using (of course: vendor specific) function-registering janitor frameworks instead of RAII (which is imho a superior way to do this, but that is certainly a subjective view). Namespaces were used inconsistently (or completely neglected, most of the time) with most types and functions ending up polluting the global namespace, no sense of forcing constness of parameters (although thats strictly speaking a C99 feature as well), using dynamic_cast<> where reinterpret_cast<> would have been the better choice, etc. . The horror.
Don’t get me wrong: I consider the –(C++) C – alike core of the language (in combination with template functions, function overloading, namespaces, fine grained casting mechanisms, etc.) a big asset of the language. Especially, since being a physicist I had my share of colleages used to the Fortran 77/90 way of things submitting languages like Java into obedience, which have no notion of a seperate, stand-alone function.
But refusing to use the tools the language provides to improve quality and performance of the code due to (as I have to sadly assume after talking to some developers of said SDKs) a substandard knowledge of the language is simple unacceptable and not a sign of “good C++”. Neglecting concepts like RAII and scoped locks just because “OO is overrated”, reinventing the (STL) wheel over and over again just because “templates are teh evil!” are signs of poor craftmanship. Period.
You can blame the language for being overly complex and for dragging a lot of baggage along due to the history and desired (syntax-) backwards compability, thus increasing the possible ways one can fail to write good programms. I am a bit old fashioned in this regard and tend to place a not too small share of the blame on the folks that try to work as a C++ programmer after skipping through a “Teach yourself C++ in 24 hours” book. And I would agree that there are areas, where the language was at least a bit overdesigned and where its behaviour is – to phrase it diplomatically – unintuitive.
But dismissing C++ because of its scope and its multitude of features and capabilities, and because it is in some respects more difficult to master (although a lot more powerful than for example C) is akin to dismissing a church pipe organ because it has more keys than a piano. Besides, both are difficult to play (and can sound horrible if the operator has no clue what to do with all those keys and pedals).
This is why C++ introduced a wonder called references.
You can…in C++. Just use templates and operator overloading with your “structs” (which are just class’s with public visibility by default), ignore constructors, destructors, inheritance and member functions and go for it. Nobody is stopping you.
If you use extern “C” {} blocks you’ll even get C binary compatibility.
Edited 2008-11-01 12:20 UTC