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 view parent comment, click here.
To read all comments associated with this story, please click here.
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:2008-09-08
Member since:2006-05-26
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.
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.