This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: c_std/ and throw()
- To: Benjamin Kosnik <bkoz at redhat dot com>
- Subject: Re: c_std/ and throw()
- From: Jason Merrill <jason_merrill at redhat dot com>
- Date: 25 Apr 2001 16:57:39 +0100
- Cc: Jakub Jelinek <jakub at redhat dot com>, libstdc++ at gcc dot gnu dot org
- References: <Pine.SOL.3.91.1010424093309.19011B-100000@cse.cygnus.com>
>>>>> "Benjamin" == Benjamin Kosnik <bkoz@redhat.com> writes:
> I think we all agree that this cfns.gperf mechanism is the way to do this
> kind of stuff. It's much cleaner that way.
For stuff in the C standard, yes. For POSIX stuff and other C code, we
will still need some sort of annotation in the header, and throw() seems
like a reasonable choice. But I suppose we don't need to worry about such
functions in libstdc++.
> Could you use something like the --enable-c99 flag that the library is
> using? Ie if the user actively wants C99 support and configures with it,
> then the extra C99 functions are added to cfns.gperf. That seems to match
> the way the library is now configured.
I think making this a configure-time choice is wrong, for the library as
well as the compiler. Most users don't build their own libstdc++. Can't
it be controlled by a predefined macro?
> I don't see a way to turn this on and off on the command line. I'm
> historically bad at seeing ways to do things that way though.
For the compiler, it's just a matter of adding a second field to the
elements of cfns.gperf, and the associated changes in code that uses it.
Jason