TR library extensions

[Gabriel Dos Reis]

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