This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: TR library extensions
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