RE: TR library extensions

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

Gabriel Dos Reis wrote:
> | A -std= option is needed that adds include/tr1 to the include path,
> | because the new tr1 headers should not be visible if -std=c++98 is
> | given.
> 
> Why?

Consider the program

#include <tuple>
int main() { }

The documentation for the -std switch says:
  Specify the standard to which the code should conform
This code doesn't conform to C++ 98 (because there is no header named
<tuple>). Shouldn't the compiler reject it when -std=c++98 is
specified?

> the TR1 resides in a separate namespace (excep for a very few).

The namespace tr1 is not in namespace tr1 :-) Also users may define
macros with names that conflict with the new components.

#include <functional>
class tr1 { /* some stuff */ };
namespace std
{
  template<> struct less<tr1> { /* more stuff */ }; 
}

This is valid C++ 98 code, but it's broken by the TR. std::tr1
shouldn't be defined in any header if -std=c++98 is specified.

> | A preprocessor macro is needed for the same reason (as some
> | proposals make changes to existing components). Maybe -std=tr1 and
> | __TR1__ ?
> 
> __LIBCXX_TR1__?
> 
> We should be aware that we're not the only project.  We should make it
> clear which symbols are ours (or C++'s), preferably in the spelling.

Yes.

Most of the above is discussed in clause 1.3 of the TR. 

> | The implementation will probably take a while to settle down. Should
> | the additions be put in a separate library so that non-compatible
> | changes can be made without breaking programs that only use C++98?
> 
> I don't understand this.

What I'm asking is this: Should the major version of libstdc++.so
change when non-compatible changes are made to TR components?
This can be avoided by putting the TR in separate .so and .a files
(maybe libc++tr1.a and libc++tr1.so).

Petur

P.S. Is the namespace for the TR components ::std::tr1 or ::tr1 ?
I think I have seen the former mentioned somewhere, but 1.3 seems
to imply the latter.