In case anyone is a language lawyer, say goodbye to the C++ export keyword. It's officially removed from the C++0x language standard. This isn't a change that will affect most people since only 1 compiler actually supports it, but exception specifications were deprecated too and this is rather interesting. They've always been a topic of heated debate (just look at Java), but personally I'm thrilled to see them go the way of the grave. Click for more

\o/

Committee reports are fun to read.

The FCD is AWESOME news. Yay! Good job committee!

Quote:Also boo at the committee for taking so long to arrive at the correct solution. After more than ten years, this feature was supported by a single compiler; all research showed that implementing it was tremendously difficult; the sole implementors specifically recommended against it; no backwards compatibility could conceivably be broken, since this feature wasn't even available to end-users.

The importance of the keyword was it's political value, not semantic value.

Looking back to 1996, template compatibility was the biggest issue blocking the standard. The draft had been 'closed' to new features and substantial changes, but there was still a lot of debate over template details. It seemed like every day saw a new application (and abuse) of templates. There was a lot of fear over template portability.

Template compatibility was delaying the standard. Nobody was certain how templates would eventually settle down, and there was a fear of compatibility. Vocal groups demanded compatibility in the standard. Other vocal groups said the needs could not be guaranteed. Nobody could come up with an answer. Neither side could declare "it can be done", or "it cannot be done".


People were discovering new uses (and abuses) of templates every day. The keyword took advantage of that. Those vocally concerned about portability were assured that it would be added --- if possible. To them, the keyword meant they could force vendors to add it when the answer was found. Those concerned that it couldn't be done were assured that the people who were (ab)using templates would dig into the issue. For them, the keyword was something they could ignore unless the community at large found a way to resolve it.

Adding the keyword effectively said "We don't know how to answer the portability question. If any of the millions of creative programmers around the globe figures it out, it is supported in the standard." Given the situation, it was a very diplomatic solution that resolved a major dispute. Without the keyword, the 1998 version of the standard could have easily been a 1999 or 2000 version.

No, they aren't checked at compile time.

Quote:Original post by jwezorek
Man, I didn't even know about exception specifications... Are (were) they like checked exceptions in Java?

They are very different than the Java versions.

The C++ exception specification was essentially a catch() wrapper around the function. If it caught anything and it wasn't one of those exceptions, it would call terminate(). Any unspecified exception becomes an immediate program termination.

An empty specification might also be used as an optimization signal that the compiler it doesn't need to generate unwinding information in specific circumstances. This varies by compiler. It optimization signal is being replaced by the noexcept keyword. It is still mostly an optimization signal, and from what I've seen so far, looks to be completely ignorable.

Another interesting thing to come out of this meeting is some details of lvalue/rvalue.

The two almost always worked, except when describing certain reference objects. (Sutter wrote about it in the article 'The most important const').


They added an xvalue (eXpiring value) which has always been considered an rvalue and sometimes been a valid lvalue. It now gets its own formal classification.


Ripple effects:

The traditional non-expiring rvalue is called prvalue ("pure rvalue"). The rvalue is now xvalue + prvalue. Basically they removed the special case from rvalue and called the general case 'prvalue'.

When something could be either an lvalue or an xvalue, it is now a glvalue.

glvalue = lvalue + xvalue;
rvalue = rvalue + xvalue;