Re: A Brief Look at C++0x
Posted: Jan 7, 2006 12:32 PM
By the way: I realise after having posted a reply to your posting at Slashdot, that I was a little harsh, and have posted a follow-up to it, where I retract some of it (yet to appear at Slashdot).
You see, I am on the C++ standards committee, and I get a little tired of hearing complaints about too little being done with C++.
Unfortunately, I haven't had much chance to contribute, myself, due to other commitments, but I at least participated at the Lillehammer meeting last spring (where among other things, proposals for "concepts", modules, and memory model (for concurrency) were being discussed and refined), and I'd like to participate at the Berlin meeting next year, as well, if I get a chance to. However, at least I don't complain about the other people who actually do contribute to the standards work, and do some excellent work. The "concepts" proposals (there are two of them, but they might be merged), for example, are really big things, and the authors of one of them have made a prototype implementation in GCC, in three full-time months (which I found to be a surprisingly short time, but it's a prototype, and apparently quite slow). How many of us would be able to take that much time for standards work, unless you're doing it as part of study (which I think was the case here)?
One shouldn't underestimate the amount of work going into even "smaller" features (making sure it works in all cases, provide "standardese text" for the standard, participating in discussions, perhaps making prototype implementation, to show implementability, etc.). For one thing, some issues are often considered "small", due to ignorance of the actual complexities involved. Take things like overload resolution, which is very complex, once you study that part of the standard. If you really think it's "simple" and "easy", come to a standards meeting...
Regarding your reply to Mr. Stroustrup:
"That done, try putting yourself in the shoes of the committee and decide how to proceed.
It's easy: implement all the proposals. They are not that many or that difficult to implement anyway."
I think you're grossly underestimate the issues involved in standards work, and the complexities involved in the various features. Have you actually read the proposal papers at the standards site?
However, if you do think it's so easy to do this, then by all means, any help would be most welcome, and you might get a different understanding of the amount of work that goes into this...
> if people like yourself (who want these things)
> participate in the language development, we could probably
> have had done more, by now.
> Where do I sign up???
I'm no expert on standards work, but one of the things that have been suggested, is to read through the proposals that interest you, to get an understanding of the issues involved, and possibly the status of the proposal. Then, you might mail the author, asking if there's something you can contribute with.
I know, for example, that Thorsten Ottosen is working on a DbC-proposal, that he has presented a couple of times to the committee (with a revised version, of course), but he's concerned that although quite a few people on the committee expresses interest in it (I think it could be great for C++, too, and possibly complement "concepts", where concepts check compile-time properties, and contracts check run-time properties, of classes and functions), there may not be enough people to care _enough_, for it to happen (to become a feature of C++0x). From what I've heard, he's working on a prototype implementation of it in GCC, but like many people, is also very busy (doing both work and study, as well as this). People like him, and others working on other proposals, I'm sure would welcome any and all support and contribution.
One can also write a proposal, oneself (although it might not have much chance to get much consideration, at this point, perhaps unless it's an "important" feature, and you're willing to do much of the work with it, yourself, as many on the committee are busy with the existing proposals).
To run through some of the proposals in your list:
"-No true message passing."
Boost.Signals does this quite well, not requiring you to specify the interface up-front.
You talk about the "run-time structure" of a class, but also say this will have no run-time overhead, so I'm guessing you mean compile-time introspection information (or what to call it). Bjarne Stroustrup has an XTI (Extended Type Information) project, that provides this information at run-time, and then there's Daveed Vandevoorde's "Metacode" extension proposal, for making the type information available at compile-time, and for making metaprogramming easier, being able to use normal C++ syntax for it.
"- the lack of import declarations."
You might want to look at Daveed Vandevoorde's "module" proposal, as it deals with some of this (getting a module system in C++ is under active consideration).
"- no variable argument lists in templates."
I'd really like to have that one, too (and there exists a proposal for it), as it would, for one thing, enable "perfect forwarding" (together with the "move"-proposal, which seems to have a good chance of making it in the next version of the standard), without cumbersome/limited, and combinatorally explosive number of manually declared overloads/specialisations, but again, someone has to do the work of bringing it to the end.
And so on. "Lambda-functions/closures"? Yes, please. When can we get it? :)
One of the things I brought up at the Lillehammer meeting, when a list of "active proposals" (proposals to work with in the time to come up to the next version of the standard), was that partial specialisation of function templates was missing from the list, and I pointed out that there existed a formal proposal for it (from many years ago), so it was added to the list of active proposals. This would nicely fill out a "hole" in the type system, as you can fully or partially specialise class templates, but only fully (not partially) specialise function templates. This means you can't, for example, specialise std::swap for a class template (and overloading functions in the standard library is not allowed, and is position-dependent, i.e. the overload being selected depends on whether or not it has been seen before the function call, unlike specialisations, which are selected after overload resolution). However, if noone works on it, completes it, it may not get done...
> I think that breaks C++ constructor/destructor model
> (when are the destructors called?)
> Why does it matter when destructors are called? when using
> garbage collection, destructors become almost irrelevant
> for heap allocated objects. After all, C++ has RAII, which
> is a much better way to release resources than any
This one puzzled me, too. Destructors is an essential ingredient to RAII in C++... RAII is a technique where you allocate in the constructor, and release in the destructor.