> Nobody is trying to "turn C++ into Java." The committee is
> interested in standardizing existing practice. We should
> standardize threads for the simple reason that lots of
> people are writing multi-threaded C++ programs today. To
> not put threads in the standard would be to ingore the
> needs of real C++ programmers.
I picked this message to reply to more or less randomly. I just wanted to thank Eric on a most useful piece of reporting. All too often people ignore the standards process, only to loudly complain when the result doesn't meet their needs - or they think the standard doesn't meet their needs. The committee consists of volunteers - often very dedicated and hard-working volunteers, who devote significant time to explain what's going on and to make information available (Can you search for "WG21" on the web? If you do, you'll find all the proposals - more than you even wanted to know).
The C++0x effort are trying to address what many experienced people see as the key problems for the C++ community. It is trying to address them responsibly, with very few resources (i.e. people, money, and time), and in a timely manner. Doing all three is *hard*. See my papers on the direction of C++ (on my publications page:
http://www.research.att.com/~bs/papers.html).
It is now pretty certain that C++0x will
(1) address the serious issues about machine model raised by modern hardware - the standard will address these issues exactly so that "the average programmer" will not have to understand these issues - the language will (at the user level) present a reasonable model of the machine.
(2) provide a reasonably simple, portable, and conventional model of threading. It may provide "futures" as a mechanism to save many users from explicit locking. I wish it would also provide some form of message queues, but that is almost certainly not going to happen in this time frame. The committee uses Technical Reports (TRs) to address issues beyong the C++0x timeframe. Threading is a pretty awful way of dealing with concurrency, but it is so widely used that C++0x must address the issue. Purely library-based approaches can't handle real concurrency (e.g., as presented by multi-cores), so there will be some code language support (e.g. for thread local storage and initialization).
(3) Programmer-controlled garbage collection, as first suggested by me in 1994 or so, primarily based on the work on Hans Boehm (available open source and and used industrially with C++ for about 15 years now). If you don't like it, you turn it off (actually, the default is "off", so it's more correct to say "if you want it, you turn it on").
(4) Lots more. More than I can mention here - again see my publications page, "WG21", and my C++ page.
-- Bjarne Stroustrup:
http://www.research.att.com/~bsPS. Try to read Eric's article (again) and other articles. See what's actually written and proposed, rather than just imagining. And please do remember that you couldn't possible get all you could wish for.