Re: TR library extensions

[Gabriel Dos Reis <gdr at integrable-solutions dot net>]

Pétur Runólfsson <peturr02@ru.is> writes:

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

I see no reason.  Do you also propose to reject

   #include <unistd.h>

   int main() { }

?

| > the TR1 resides in a separate namespace (excep for a very few).
| 
| The namespace tr1 is not in namespace tr1 :-)

So?

| Also users may define macros with names that conflict with the new
| components. 

C++ programmers that rely on macros know that sonner or latter, their
programs will break (tm).


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

The cure simple: 
  (1) qualify your names.  This is not new.
  (2) configure your compiler at installation time, just like you
      configure for C99 goodies.

[...]

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

TR1 is known as experimental, it can change at any moment; users know
they can't count on ABI compatibility as far as TR1 is concerned.

TR1 is a moving target.

Also, it is obvious to me that the TR1 inclusion is specified at
configuration time.  That is how we handle other experimental
features. 

Basically, I'm not convinced that should mess with -std= thingy.

| This can be avoided by putting the TR in separate .so and .a files
| (maybe libc++tr1.a and libc++tr1.so).

yes, multiplication of .a or .so are best avoided.

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

std::tr1.

-- Gaby