------- Comment #29 from hhinnant at apple dot com 2006-01-12 00:59 -------
(In reply to comment #28)
> Subject: Re: exception_defines.h #defines try/catch
>
> | No, "try" in this context is not a keyword.
>
> I did not say it was a keyword. I know what it is in that phase.
>
> try/catch are special when -fno-exceptions.
In the preprocess stage, try/catch are not special when -fno-exceptions
according to the compiler. They are only special at this stage according to
libstdc++, and for no reason I find convincing.
> | > Can you provide standard specs that says the program must work with
> | > -fno-exceptions?
> |
> | Of course not.
>
> Then stop claiming that your use was conformant.
*No* program is conformant if it uses -fno-exceptions (by definition). I'm
claiming that this demo is conforming if it does not use -fno-exceptions. I'm
also claiming that it does not use the C++ try, catch, or throw, and therefore
is an excellent candidate to work correctly under -fno-exceptions.
> | I would rather not document that the libstdc++ takes a position
> | contrary to the compiler
>
> It does not take a position contrary to the compiler. It complements
> the compiler, with its own additional requirement. That is not new.
The mere inclusion of <vector> breaks the conforming C++ program (under
-fno-excepttions).
#include <stdio.h>
#include <vector>
#define glue(a, b) a ## b
#define xglue(a, b) glue(a, b)
#define tryLOW "hello"
#define LOW LOW ", world"
int main()
{
printf("%s\n", xglue(try, LOW));
}
I realize that once the customer specifies -fno-exceptions, all bets are off.
Nothing has to work. Not g++, not libstdc++. But there has obviously been
effort to make g++ and libstdc++ work under this environment. I'm simply
pointing out that the effort could be improved. Obviously no standard is going
to back this view up.
We have a conforming C++ program, which does not use try/catch/throw, which
works as expected under -fno-exceptions if you don't include <vector>, and
breaks if you do. I think libstdc++ can and should do better than that. We
have customer complaints on this issue. I'm developing a library-based patch
to improve our support in this area.
> The way you solve this is to make the front-end complete
If you want to lead an effort to improve support of this issue in the front
end, that sounds really good to me. Please do. Note that this solution will
still involve libstdc++ being changed to not #define try and catch (which is
the fundamental problem).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191
