TR library extensions

[Pétur Runólfsson]

Gabriel Dos Reis wrote:
> Do you also propose to reject
> 
>    #include <unistd.h>
> 
>    int main() { }
> 
> ?

I don't have anything to add to what Martin has already said about
this.

> | Also users may define macros with names that conflict with the new
> | components.
> 
> C++ programmers that rely on macros know that sonner or latter, their
> programs will break (tm).

I don't recall many useful programs that don't rely on macros.

> | #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.
It's a conforming program, and there is already a lot of code in
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
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.

> | This can be avoided by putting the TR in separate .so and .a files
> | (maybe libc++tr1.a and libc++tr1.so).
> 
> yes, multiplication of .a or .so are best avoided.

It see 4 possibilities:

1) Put TR code in libstdc++.so, and increment the major version
number when incompatible changes are made.

2) Put TR code in libstdc++.so, but don't increment the major
version number when incompatible changes are made to TR
components.

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.

4) Put TR code in a different .so (possibly built only if a
configure switch is used).

I'm not sure which (if any) of these options you are suggesting.
I like option 4) best, since it doesn't affect users that don't
use the TR1 features.

> 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.

Petur