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: local policy)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: status of <type_traits> with gcc
Date: Thu, 26 Jun 2008 16:55:34 -0600
Message-ID: 
 <CFFDD219128FD94FB4F92B99F52D0A4901E0FBFF@exchmail01.Blue.Roguewave.Com>
Thread-Topic: status of <type_traits> with gcc
Thread-Index: AcjX3F/zJ9oMsHrvSiODtv8Kq2PJdQAAun+g
References: <4863C50E.10702@roguewave.com>
 <CFFDD219128FD94FB4F92B99F52D0A4901E0FBFD@exchmail01.Blue.Roguewave.Com>
 <4864188E.9040605@roguewave.com>
From: "Travis Vitek" <Travis.Vitek@roguewave.com>
To: <dev@stdcxx.apache.org>

=20

>-----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:
>> =20
>>=20
>> 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?
>>>
>>=20
>> I just did a sync of 4.3.x and a build with =
CXXFLAGS=3D"-std=3Dgnu++0x
>> -D_RWSTD_EXT_CXX_0X" and didn't run into any problems with=20
><type_traits>
>> or the 20.meta.*.cpp tests (though 20.forward.cpp and
>> 26.valarray.cassign.cpp both fail to compile).
>>=20
>> I did another build without those flags and I do see some=20
>compile errors
>> in both the traits and tuple code. I'll fix the traits issues.
>
>Thanks. I hadn't realized I needed -std=3Dgnu++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.

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=3Dgnu++0x. Now they
might get a link error, right?

Travis