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:2008-09-08
Member since:2005-11-11
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.
Member since:2005-07-06
*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..
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:
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.