Future evolution of c++config.h and _GLIBCXX_USE_LONG_LONG

[Gabriel Dos Reis]

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