Linked by Thom Holwerda on Thu 30th Oct 2008 12:53 UTC, submitted by CPPfanboy
General Development 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)."
Thread beginning with comment 335783
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[2]: concurrency
by japh on Fri 31st Oct 2008 08:31 UTC in reply to "RE: concurrency"
japh
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.

Reply Parent Score: 1

RE[3]: concurrency
by bleedingedges on Fri 31st Oct 2008 14:40 in reply to "RE[2]: concurrency"
bleedingedges Member since:
2008-09-08

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.

Reply Parent Score: 1

RE[4]: concurrency
by japh on Fri 31st Oct 2008 14:50 in reply to "RE[3]: concurrency"
japh 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.

Reply Parent Score: 1

RE[4]: concurrency
by renox on Fri 31st Oct 2008 23:09 in reply to "RE[3]: concurrency"
renox 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..

Reply Parent Score: 2

RE[3]: concurrency
by JonathanBThompson on Fri 31st Oct 2008 20:13 in reply to "RE[2]: concurrency"
JonathanBThompson 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.

Reply Parent Score: 2