This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: Future evolution of c++config.h and _GLIBCXX_USE_LONG_LONG
- From: Gabriel Dos Reis <gdr at integrable-solutions dot net>
- To: Matt Austern <austern at apple dot com>
- Cc: libstdc++ at gcc dot gnu dot org
- Date: 12 Jan 2005 00:40:21 +0100
- Subject: Re: Future evolution of c++config.h and _GLIBCXX_USE_LONG_LONG
- Organization: Integrable Solutions
- References: <A9C028E6-6422-11D9-86F0-000A95A4FA9E@apple.com>
Matt Austern <austern@apple.com> writes:
[...]
| That's where I start getting nervous. I see two options, and I'm
| nervous about both of them. I hope someone here can tell me not to be
| nervous about at least one choice.
|
| Choice 1: Libc headers should always expose long long functionality
| whenever those headers are compiled as C++. This makes me nervous
| because it means there will be no way for users to get full standard
| conforming C++ on Darwin. If libstdc++ evolves to allow turning long
| long on and off at the level of an individual compilation, then a Libc
| that exposes long long unconditionally won't be able to take advantage
| of that.
|
| Choice 2: Libc headers should all include c++config.h and test
| _GLIBCXX_USE_LONG_LONG. This makes me nervous because c++config.h and
| everything associated with them are internal to libstdc++.h, and
| there's no reason to think this solution will work in future releases.
|
| I'm leaning toward choice 1: it's inelegant but probably safe. Anyone
| want to give me arguments in either direction, or suggest a third
| choice?
The impermeable separation of libc from libstdc++ is the root of many
headaches and unnecessary kludges. For example, it means that it is
quite difficult to implement <cxxx> and <xxx.h> correctly. It also
means that one gets into the trouble you're describing.
At several occasions, Benjamin and I and others (I think I remember
Joe) have expressed the idea that we should look for better
cooperation between libstdc++ and libc implementers, meaning that
libstdc++s should provide hooks for libc so that exceptions match on
both sides. (I believe there are some bits of that in glibc).
In particular, I think Choice 2 is in the good direction. We can
agree on, for example, that _GLIBCXX_USE_LONG_LONG is alsways going to
set be honored -- even in C++0x :-)
The impermeable separation between libc and libstdc++ is purely
abstract and unproductive.
-- Gaby