On Fri, Mar 21, 2008 at 3:50 PM, Brian Dessent <brian@xxxxxxxxxxx> wrote: > Jason Cipriani wrote: > > > One feature that I have > > always desired the most in a C++ compiler is strict enforcement of > > throw() clauses. > > Since you seem to be well aware of the design of C++ exceptions you > should realize why this is a near impossibility. In order for the > compiler to enforce a throw declaration, it would have to have complete > knowledge of the entire outbound call graph of the function. Two things > stand in the way of this: separate compilation and function > pointers/virtual functions. The problem of separate compilation (i.e. > that the compiler only has local knowledge of a given translation unit > at any time) can somewhat be dealt with by using gcc --combine, but > that's more of a crutch. It won't fix the issue that necessitated > separate compilation in the first place: the explostion of complexity as > the size of one "unit" grows. (And here I'm not speaking at all of the > human factors of keeping source units small and maintainable, I'm > strictly referring to the algorithmic complexity experienced by the > compiler.) > > Longer term, the gcc LTO project will eventually provide a better > infrastructure for whole-program optimizations, but it will still not be > able to see past library boundaries. That might not be a problem if > like you say C++ had been more Java-like and required accurate throw > declarations from the beginning. But there is just no reasonable way to > expect that now, so from a compiler standpoint the only way to implement > enforcement of throw declarations would be to "see down into" all > library code (unrealistic for all but perhaps embedded applications) or > to rewrite all library code to include accurate throw declarations in > their headers and then tell the compiler it can trust them. Either way, > it's a ton of work. > > And this hasn't even begun to address the issue of function pointers and > virtual methods, where the call graph can't even be known at compile > time. I'm sure you could construct a pathological testcase without too > much effort for which it would be provably impossible to enforce throw > declarations at compile or link time. > > However, you may be interested in Brendon Costa's EDoc++ which consists > of a hacked up gcc that embeds additional exception and callgraph data > into the objects, and a post processing tool to recover, combine, and > analyze it all at link time. <http://edoc.sourceforge.net/> I agree with all this and wanted to add: + C linkage (which may be included above) -- since C functions don't have exception specs, how should they be handled especially if they wind up calling C++ functions through callbacks + template functions -- what if the exception spec is dependent upon the template parameters? Noel
