This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: TR library extensions


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



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]