------- Comment #26 from hhinnant at apple dot com 2006-01-11 18:02 ------- (In reply to comment #25) > Subject: Re: exception_defines.h #defines try/catch > | The demo program does not play tricks with try/catch. > > It does, with xlgue(try, ....).
No, "try" in this context is not a keyword. There is no try, no catch, no exception, in this conforming C++ program. > | What subset of C++ programs do we expect to work under -fno-exceptions? > > Those that understand that try/catch are special. The intent of turning off exception handling in the compiler is to accomidate programs that are ignorant of try/catch, and have no need to process exceptions. > Can you provide standard specs that says the program must work with > -fno-exceptions? Of course not. Does this imply that we ought to lower our expectations of our product when exceptions are disabled such that it will seemingly randomly break conforming code? Or are our quality standards higher than that? > | Where do we document that some, but not all libstdc++ headers change the > | semantics of -fno-exception (as gcc documents it) and may render some > | conforming C++ programs broken? > > If the issue is that -fno-exceptions is not well documented, then we > should document it better. I'm happy to review documentation patches > that reflect the current state. I would rather not document that the libstdc++ takes a position contrary to the compiler and does not work with exception-ignorant but conforming code with -fno-exceptions. Such a position would be hard to justify. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191
