Mailing-List: contact dev-help@stdcxx.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@stdcxx.apache.org
Received-SPF: pass (athena.apache.org: domain of msebor@gmail.com designates
 74.125.46.30 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:organization:user-agent:mime-version:to
         :subject:references:in-reply-to:content-type
         :content-transfer-encoding:sender;
        b=NHRU7j2oOwqxHq4ACiuGS8x4WSnT7uEJr/1m3KBWZlaLuhe8lJlo/EjUREi8TMubGG
         LM2SopWoP7/PoKl9tNWUGHeS1QOzy/vHaKvitagIxizFMUU0B6dMMZ0SSc4Sj98arY1n
         VBTn35D+zQBDLKdvJfgReV3FCZ9Syx8+CdFMk=
Message-ID: <48656D61.2010700@roguewave.com>
Date: Fri, 27 Jun 2008 16:44:49 -0600
From: Martin Sebor <sebor@roguewave.com>
Organization: Rogue Wave Software, Inc.
User-Agent: Thunderbird 2.0.0.14 (X11/20080501)
MIME-Version: 1.0
To: dev@stdcxx.apache.org
Subject: Re: status of <type_traits> with gcc
References: <4863C50E.10702@roguewave.com>
 <CFFDD219128FD94FB4F92B99F52D0A4901E0FBFD@exchmail01.Blue.Roguewave.Com>
 <4864188E.9040605@roguewave.com>
 <CFFDD219128FD94FB4F92B99F52D0A4901E0FBFF@exchmail01.Blue.Roguewave.Com>
In-Reply-To: 
 <CFFDD219128FD94FB4F92B99F52D0A4901E0FBFF@exchmail01.Blue.Roguewave.Com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: Martin Sebor <msebor@gmail.com>

Travis Vitek wrote:
>  
> 
>> -----Original Message-----
>> From: Martin Sebor [mailto:msebor@gmail.com] On Behalf Of Martin Sebor
>> Sent: Thursday, June 26, 2008 3:31 PM
>> To: dev@stdcxx.apache.org
>> Subject: Re: status of <type_traits> with gcc
>>
>> Travis Vitek wrote:
>>>  
>>>
>>> Martin Sebor wrote:
>>>> I'm getting compilation errors with gcc 4.3. Is the implementation
>>>> supposed to be stable at this point with any compiler or are there
>>>> still some major issues?
>>>>
>>> I just did a sync of 4.3.x and a build with CXXFLAGS="-std=gnu++0x
>>> -D_RWSTD_EXT_CXX_0X" and didn't run into any problems with 
>> <type_traits>
>>> or the 20.meta.*.cpp tests (though 20.forward.cpp and
>>> 26.valarray.cassign.cpp both fail to compile).
>>>
>>> I did another build without those flags and I do see some 
>> compile errors
>>> in both the traits and tuple code. I'll fix the traits issues.
>> Thanks. I hadn't realized I needed -std=gnu++0x and was getting
>> a ton of errors. That, and I also forgot to reconfigure to get
>> _RWSTD_NO_VARIADIC_TEMPLATES #defined.
>>
>> Btw., to make using C++ 0x easier we might want to automatically
>> #define _RWSTD_EXT_CXX_0X when the __GXX_EXPERIMENTAL_CXX0X__
>> macro is #defined (and #undef _RWSTD_NO_VARIADIC_TEMPLATES and
>> other config macros #defined as a result of the absence of the
>> option during configuration).
> 
> Yeah, but some of these options might break compatibility.

I suspect it's unrealistic for us to try to constrain the C++ 0x
implementation by the rules of binary compatibility while the spec
is still in development or between pre-C++ 0x compilers and those
that provide the essential C++ 0x core features that the library
depends on.

Just like gcc users who choose to compile with -std=gnu++0x
cannot expect libstdc++ implementation of C++ 0x to stay stable
across compiler releases (either at the ABI level or at source
level), neither will be able to users of stdcxx until the final
standard is in place.

> 
> Imagine an exported function that takes an rvalue reference parameter.
> The library would be configured without rvalue references, but then the
> user 'enables' c++0x support by compiling with -std=gnu++0x. Now they
> might get a link error, right?

I don't see how they could. There's no such thing as rvalue
references in today's C++ and I can't think of any way to
emulate them. Enabling C++ 0x support (e.g., using gcc's
-std=gnu++0x option) will only add new overloads taking
rvalue references; it won't remove any.

Martin