I prefer the method Jason mentioned of including this functionality as a form of more strict checking of -Wexception-specs (Or maybe defining a new warning) as opposed to having an attribute that defines new semantics.
In the end the two are practically identical. The semantics of the existing "OLD" throw() you are describing as the exceptions that can be caught, where as the "NEW" semantics would be that the given exceptions are the only ones that can propagate from calling the given function. These are for all intents and purposes the same. In the "OLD" style the function still can only throw the given exceptions. It just so happens that the program terminates if it tries to do otherwise. The stricter checking just ensures that no other exceptions may arise and so the program wont terminate as a result. The only difference is that at compile time you will either enforce that this throw() specifier is adhered to by doing static analysis or you wont. It avoids having to define special attributes in the code, the only difference is the set of command line flags you pass to the compiler. It does however mean that you cant provide function level "enable/disable of static checking". I.e. It will check for all functions whose implementation you find in the given translation unit. Brendon. Mike Stump wrote: > On Apr 10, 2007, at 2:06 PM, Sergio Giro wrote: >> Maybe I missed some point: why everything should be rewritten? > > Let me try again. The standard way to add a new qualifier in g++, is to > add it in an attribute, please do that. The possible responses are, no, > I want to be different, or ok. If you choose the former, you have to > back your position. For throw specs, that attribute is the standard one > that goes on the function/method. The name or the spec can be > statically_check_eh_spec, or something less verbose. > >> The only bad thing here is that you have two qualifiers having similar >> meanings... > > Ding. > >> But I think it must be that way > > No, this is incorrect. > >> in order to _avoid_ rewriting code. > >> The point here is that, in order to do this, you need interprocedural >> analysis. > > You've not yet grasped they are isomorphic forms. If the above is true, > then then below is wrong. If the below is not wrong, then the above > must be wrong. Your pick. > >> If you have qualifiers as the one I describe, you can perform the >> check by merely using the prototypes... > >> So, what do you think now? > > Unchanged. > >
