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)."
To read all comments associated with this story, please click here.
Member since:2006-10-31
Member since:2006-04-14
Member since:2006-05-26
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.
Member since:2005-11-11
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.
Member since:
2005-07-08
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.