RE: TR library extensions

[Pétur Runólfsson <peturr02 at ru dot is>]

Martin Sebor wrote:
> > 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 :)

Seems it was my idea, however it isn't really important. The
main point is TR1 support shouldn't be enabled by default
(or at minimum, that if -std=c++98 is used then tr1 is
disabled). Explicit -I and -D switches are just as good
as a -std= switch (better, because a TR isn't a standard).

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

I don't think binary compatibility is an issue here. It would
be an issue if the TR added virtual functions to existing
components, but I haven't seen any such yet. 

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

GCC provides such options, -std= and -pedantic.

Petur