Thread: new standard

It's likely to not change much, but until it's been ratified (all parties have signed it), there's still a potential that something will change. The way standards works is that most of the changes to a standard happens early on. C++0x is supposed to be ratified this year [we hope, otherwise it will be 1x?], so the timeframe in which changes may be introduced is very small.

--
Mats

Some features are already set in stone (or implementors wouldn't start implementing them).

The first round of national body comments has passed. Now there is a round of fixing the problems pointed out. There won't be much more changes, unless serious problems are discovered.

One rather big change that may yet get in is an example of this, a serious exception-safety problem caused by rvalue references.
Rvalue References and Exception Safety
So we may yet get the noexcept specifier.

Originally Posted by CornedBee

The first round of national body comments has passed. Now there is a round of fixing the problems pointed out. There won't be much more changes, unless serious problems are discovered.

One rather big change that may yet get in is an example of this, a serious exception-safety problem caused by rvalue references.
Rvalue References and Exception Safety
So we may yet get the noexcept specifier.

Thanks for that, it was a really good read!

Originally Posted by CornedBee

One rather big change that may yet get in is an example of this, a serious exception-safety problem caused by rvalue references.
Rvalue References and Exception Safety
So we may yet get the noexcept specifier.

Strikes me as overkill, I must admit. rvalue references were introduced as a means of providing an alternative to common abuses (eg using a cast to work around poor use of const specifiers in a set of functions). And then it is necessary to add other constraints to prevent other problems.....

My personal prediction is that rvalue references will be actively avoided by a lot of serious programmers.

With the noexcept specifier, I consider it would have been better to turn exception specifications into static compile-time checks, rather than run-time checks. Then a "throw ()" specification would become equivalent to the proposed noexcept specifier. Since there is talk of deprecating throw() specifications anyway, there would be little loss in reusing the syntax.

My personal prediction is that rvalue references will be actively avoided by a lot of serious programmers.

Perhaps in direct use of their own. Not their effect entirely, since that can't be avoided if you use the standard library.

I don't think it will happen, though.

Then a "throw ()" specification would become equivalent to the proposed noexcept specifier.

I think the paper had a very good rationale for not doing that.

Originally Posted by CornedBee

I think the paper had a very good rationale for not doing that.

The paper listed the arguments for deprecation of exception specifications (and the underlying concern is that they are not checked statically). However, the focus of the paper was actually on fixing concerns associated with move constructors - essentially by specifying they will not throw - not on fixing wider concerns with exceptions.

The paper also noted that variants of throw specification are an alternative. On one hand, throw specifications are already discouraged and relatively rarely used (that's the core of the argument for their deprecation). Given that, the argument of "having too many syntactic similarities confuses the semantics of the two features in a way that is likely to cause problems for programmers" is a rather weak argument against overhaul of the semantics of exception specifications. Particularly when the "two features" are both related to exception handling.

Originally Posted by Perspective

Their going to add garbage collection and weak typing.

Not my understanding.

As I understand it, features are proposed that will make garbage collection easier to implement, but there is no proposal to actually support it. That strikes me as consistent with the philosophy of C++ as a "general purpose multi-paradigm" language - garbage collection is suitable for some purposes/paradigms, but not others.

I don't recall any serious consideration of weak typing. Which is hardly surprising: one of the cornerstones of the C++ type system has always been strong typing.

Garbage collection was planned (as optional, of course), but got thrown out due to time constraints. As a compromise the notion of "safely derived" pointers was introduced, which defines the restrictions on a program that wants to work with a library-based garbage collector without having the GC collect live objects.

Originally Posted by grumpy

The paper listed the arguments for deprecation of exception specifications (and the underlying concern is that they are not checked statically). However, the focus of the paper was actually on fixing concerns associated with move constructors - essentially by specifying they will not throw - not on fixing wider concerns with exceptions.

The paper also noted that variants of throw specification are an alternative. On one hand, throw specifications are already discouraged and relatively rarely used (that's the core of the argument for their deprecation). Given that, the argument of "having too many syntactic similarities confuses the semantics of the two features in a way that is likely to cause problems for programmers" is a rather weak argument against overhaul of the semantics of exception specifications. Particularly when the "two features" are both related to exception handling.

It is one thing to discourage people from using throw declarations, it is another to replace it with something else. The latter will break some existing code; the former will not.

Perhaps, if they depreciate throw declarations now, then ten years time it will make sense to replace it with something else, but no sooner.