TR library extensions

[Martin Sebor]

Gabriel Dos Reis wrote:
...
> | porting from another implementation to gcc). I don't think it should
> | be necessary to configure and install two different compilers just to
> | get functionality that can be easily provided by one. Not all users
> 
> consider how you link separately compiled translation units and agains
> which library you will link.

That should be and in most other cases is handled "behind the scenes"
by the compiler. Just like -pthreads might #define _REENTRANT and
selects -lpthread to link with.

> 
> | can configure and install compilers on their systems. I'm sure you
> | don't expect to have to install a separate compiler for debugging
> | or thread safety
> 
> Guess what?  You've to configure GCC to enable thread safety support.

Yes, but I don't have to install two different compilers to use
libstc++ in a thread-safe way for thread safety or not, do I? Or to
use -pedantic, or to turn on -g or #define NDEBUG, etc. The -pthreads
option (or its equivalent) selects the APIs and the libraries for me,
all the while using the same installation of gcc.

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.

Martin