TR library extensions

[Gabriel Dos Reis]

Martin Sebor <sebor@roguewave.com> writes:

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

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?

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

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

[...]

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

-- Gaby