Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

C++0x - export gone, exception specs deprecated. Will this affect your code? [closed]

Tags:

c++

c++11

I've been programming in C++ since cfront 1.0, and I am happy to say I've never written an exception specification or allowed one in code that I was responsible for. When they were proposed, I called Bjarne Stroustrup on the phone and cried, "Don't do it!" I gave all the reasons why they were a horrible idea. To my surprise, he said something like, "I know." When I asked why the feature-from-Hades was going into the spec, he said there was a Big Player whose "experts" resolutely insisted that it had to go into the spec or they would absolutely not sign off, period, end of discussion. If I ever knew who it was, I've forgotten.

I've been deprecating a long time. :-)


Certainly no sleepless nights on any of the codebases I have been involved with over the past 5-6 years. I don't think I've ever encountered anybody who used export, plus experts like Herb Sutter have been railing against exception specifications (apart from nothrow) for so long that most programmers have got the message by now.


export was never implemented properly in gcc or MSVC, (but apparently was so in EDG/Comeau, as comments say), but I'd guess it never got widespread acceptance. (But I mainly live in the gcc/msvc world, so my viewpoint doesn't encompass the entire C++ community.)

As for exception specs, I believe they were broken too.

Third, deprecation doesn't mean will-cause-compiler-errors. It's just strongly suggested that user shouldn't use it and, if applicable (not so much here, I think), move on to other mechanisms to achieve the same goal.


I certainly won't shed a tear over exception specification. ("A good idea which, unfortunately, never worked out.") All they ever were good for were what now noexcept stands for.

But I had hoped that export would make it. As the very least, export would allow you to change helper functions for templates without having to re-compile all the code using those templates. And it would get us rid of all those detail namespaces:

namespace detail { // actually we don't want this public, but can't avoid it
  template<typename T>
  void f_helper() { /*---*/ }
}

template<typename T>
void f() {detail::f_helper();}

void g() {f<int>();} // has to recompile if f_helper()'s implementation changes

Alas, since only one of the compilers I had to use during the last decade ever implemented it, I could never use it.


I think both moves are good and neither will cause me any pain and I like the clarification of intent with regards to noexcept.


Anyone who thinks noexcept is a good idea needs to read this 3 part series. Here's part 3, the conclusion:

http://www.informit.com/guides/content.aspx?g=cplusplus&seqNum=483