TR library extensions

[Martin Sebor]

Gabriel Dos Reis wrote:

...
> The most interesting thing is to detail the "behind the scenes".
> You have to work that those details.  You can't just hand wave.
> 
> -pthreads does not have the same weight as -std=tr1.  
> 
> What does std=tr1 mean?  C++98 + TR? C++03 + TR? C++0x + TR?

I didn't come up with the name and I'm not advocating its choice here
(my personal preference would have been to follow POSIX and #define
some macro to the value of the date the standard, the TR, or a
particular implementation thereof was released). Whatever it is,
though, I expect you (the implementor) to define what it means if
you plan to provide support for it, and I expect us (the C++
committee) to require that you do so in one way or another :)

> 
...
> If you have different thread models, you have to install different
> compilers. 

I've been using gcc -threads and gcc -pthreads with the same compiler
on Solaris (at least with 2.95.2), so unless that's changed I think
you're mistaken (or we're talking about different things).

> 
> [...]
> 
> | In this case, it seems trivial to stick these extensions in a separate
> | directory that's not on the preprocessor search patch unless -std=tr1
> | is on the command line, or to add an #error directive to the top of
> | each extension header guarded by an #if !__TR1__. It improves the
> | quality of the implementation and the effort is minimal.
> 
> If it is that simple, then put -D__LIBCXX_TR1__ on command line. 

That's fine with me (although I suspect that it is not that simple
because of the binary compatibility issue brought up by Petur).
Note that I didn't write specifically in support of the -std option
but in support of any such mechanism:

 > a quality implementation of C++ such as gcc
 > should provide an option for programs to choose the version of the
 > C++ standard they want to conform to, and the compiler should
 > diagnose detectable violations when the option is selected.

Martin