Well, it’s not an easy question to answer and the picture for the core language and the library are different.

The original standard wasn’t all done within the WG21 ISO process, especially with the core language part: It came in as a base document (the non-annotation parts of the ARM), and some bits also came from the nearly finished C standard I believe (e.g., the preprocessor). So if one uses “page count” as a rough approximation, I don’t think we can compare the 300pp->400pp growth in C++0x core language specs against “300pp” in the original: Most likely the original standardization process added much less than 300pp to the base documents.

Similarly, looking and postings and proposal volumes isn’t a good comparison either. Much of the first standard was developed with relatively minor networking support: Many carried around multi-kilogram postings in paper form, not everyone at the meetings had a laptop even in 1995 (passing around a floppy was the high-tech alternative), and “distribution” during committee meetings meant dropping off a pile of copies on a designated table in a conference room. All-in-all, I think that much of the “hashing out” process that is now relatively transparent via the reflectors and multiple paper revisions had an similar-but-opaque counterpart in offices worldwide.

That said, my sense is that wrt. the core language, the two efforts produced comparable amounts of features, but the first effort was more “revolutionary” in its work by developing the specs for templates and exception handling in particular (the base document mostly just had a sketch for these things). On the flip side, I think the C++0x additions have noticeably better wording (and hopefully that will help get implementations to better match each other).

I cannot say much about the library, but I’m pretty sure that nothing matches the “revolutionary” aspect of integrating the STL in the WP of round 1.

Thanks for the kind words and the interesting meeting notes.

I’m honored to even potentially contribute to your novel work. Seems like there is great distance between idea/intention and standard level formulation.

I most credit you for challenging my original proposal to relax the strong guarantee altogether (LWG DR #985). I then tried to figure how to allow throwing move (favoring usability) without over-complicating the current specification in a way that seems hard to follow (e.g. adding conditional strong guarantee and specialization for pair[string, legacy-type]).

Though not in the same magnitude, allowing throwing move reminds me of allowing throwing copy that, AFAICT, was forbidden until late stage of C++98 standardization. It also favor usability while not over-restricting the (library) implementation. I wonder if you got push-back when you proposed “allowing throwing copy” back then…

Thanks, Rani

Yikes! Great catch; I’ll make that fix right away.

So, is noexcept part of the function type or not? What about function pointers? What about template argument deduction?

template<bool NE> void foo( void(*pf)() noexcept(NE) ) {}

Well, you can read through the proposed core language changes to be sure, but since it sits in the grammar right where exception-specifications are today, I expect the rules are the same for noexcept.

SomeCppGuy: Please, just complete the standard before trying to make it smarter and nobody will say: “oh, you missed a spot” because you have already covered all others (Quote)

As for a lot of the cut features, I have a feeling that they will be emerging in boost in one form or the other (if they are not already in anyway in some form); the ordeal for the new standard did bring a lot of interesting material.

Best Wishes,

A concerned developer.

Thanks for the feedback. Unfortunately, you’re sorta preaching to the choir over here. The only new things I want to add at this point are fixes for things we broke by adding other features (for example, adding rvalue references broke the exception-safety guarantees of vector::push_back, and we really can’t fix that problem without crippling vector w.r.t. move semantics or adding a new language feature like noexcept). That means I have to be circumspect about some really good ideas that would make everything better for everybody, like generating default implementations of move constructors akin to our default copy constructors as proposed by N2953. I like that one so much that I couldn’t bring myself to actually vote against it; In that one case I voted “neutral” instead. In general, though, I think the committee did an admirable job of killing off or postponing non-essential features in Santa Cruz; a lot of things that might otherwise be worth pursuing were stopped (e.g. SCARY iterators, the range template, and unified function syntax). Now if we could just get people to hold these proposals until after C++0x ships so we could stop spending committee time on them…

If an exception is thrown other than by the copy constructor or assignment operator of T there are no effects.

Option 1 above is a premature pessimization, sort of like indiscriminate object-level locking for concurrency: there’s no reason to think the client needs the strong guarantee at this level of granularity. Option 2 is less evil, but it will in some cases force clients to needlessly pessimize their code, e.g. by using copy-and-swap to get the strong guarantee when the algorithm actually provides (but does not promise) it.