开发者

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

开发者 https://www.devze.com 2022-12-23 01:17 出处:网络
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references,or expertise, but this question will likely solicit debate, a
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance. Closed 10 years ago.

This latest Herb Sutter trip report on the C++0x standardisation process indicates that the committee has decided to completely drop the "export" concept f开发者_开发问答or templates, and to deprecate exception specifications.

I think these are both good moves, but I'm interested if anyone out there has a code base where these changes will cause them sleepless nights?


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


I imagine that any compiler that supports them now will continue to support them for the forseeable future as optional extensions so that people can still compile their existing code.

0

精彩评论

暂无评论...
验证码 换一张
取 消

关注公众号