This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: TR library extensions
- From: Gabriel Dos Reis <gdr at integrable-solutions dot net>
- To: Pétur Runólfsson <peturr02 at ru dot is>
- Cc: <libstdc++ at gcc dot gnu dot org>
- Date: 06 Oct 2003 20:38:06 +0200
- Subject: Re: TR library extensions
- Organization: Integrable Solutions
- References: <07D05A69A3D0C14FAEA60C3ACE8E5564028D0E47@mail.ru.is>
Pétur Runólfsson <peturr02@ru.is> writes:
[...]
| > | #include <functional>
| > | class tr1 { /* some stuff */ };
| > | namespace std
| > | {
| > | template<> struct less<tr1> { /* more stuff */ };
| > | }
| > |
| > | This is valid C++ 98 code, but it's broken by the TR. std::tr1
| > | shouldn't be defined in any header if -std=c++98 is specified.
| >
| > The cure simple:
| > (1) qualify your names. This is not new.
|
| I agree that this is bad style, but that's beside the point.
No, it is not beside the point.
| It's a conforming program, and there is already a lot of code in
It is a conforming program accepted by a given compiler configured
with given options. If you install the compiler with TR1 enabled,
you're prepared to accept the TR1 semantics.
| libstdc++ to support such programs (the __, _S_ and _M_ prefixes,
| this-> and std:: qualifications etc.).
|
| > (2) configure your compiler at installation time, just like you
| > configure for C99 goodies.
|
| The gcc and glibc headers hide C99 stuff if -std=c89 is used. I
I'm talking about the C++ component. If you configure your compiler
with C99 goodies enabled, you'll still be able to use them even with
-std=c++98.
| don't see why the same shouldn't apply to -std=c++98 and libstdc++.
|
| > | What I'm asking is this: Should the major version of libstdc++.so
| > | change when non-compatible changes are made to TR components?
| >
| > TR1 is known as experimental, it can change at any moment; users know
| > they can't count on ABI compatibility as far as TR1 is concerned.
| >
| > TR1 is a moving target.
| >
| > Also, it is obvious to me that the TR1 inclusion is specified at
| > configuration time. That is how we handle other experimental
| > features.
|
| That seems reasonable, but it still leaves open what to do when
| TR1 has been specified at configure time.
include TR1 semantics. Just like we do for C99 stuff.
[...]
| 3) Put TR code in libstdc++.so and increment the major version
| when incompatible changes are made, but only if the TR was
| specified at configure time.
Yes.
[...]
| > Basically, I'm not convinced that should mess with -std= thingy.
|
| It seems OK to make users specify -D and -I options to get to the
| TR components, at least initially.
And there ought to be a configure option to enable/disable TRs.
-- Gaby