Prev: VS 2005 compiler died on this recursive template
Next: o.k. to use boolean expression as array index?
From: Andrew on 17 Mar 2010 01:48
Now that exception specifications are going to be deprecated and
throw() is going to be replaced with noexcept, presumably for the
various dtors in the std library, I wonder what is going to happen
when it comes to compiler warnings and errors.

At the moment I get exception-related compile time errors from GCC for
some code I am working on (I didn't write it). The code has classes
that inherit from std::exception but the dtor does not say throw().
When I add throw() the compilation error goes away. The code is
developed with the Microsoft Visual Studio compiler where you don't
get that particular error. I would like throw() added to increase
portability. Its presence is not harmful to Studio but it does help
with GCC. My concern is, what would happen if I added them and then we
moved to an environment where exception specifications are deprecated.
Would I get warnings for using a deprecated construct? Or would I get
get an error for a dtor signature mismatch (not saying noexcept where
required)?

I don't want to advocate using constructs I know are going to be
deprecated but what to do about the GCC errors? Can throw() be
replaced with noexcept throughout? If so then perhaps this is my best
bet. I could always replace throw() with noexcept using good old
global search and replace.

Regards,

Andrew Marlow

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

 | 
Pages: 1
Prev: VS 2005 compiler died on this recursive template
Next: o.k. to use boolean expression as array index?