status of with gcc

[Martin Sebor <se...@roguewave.com>]

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?

Thanks
Martin

Re: status of with gcc

[Martin Sebor <se...@roguewave.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

RE: status of with gcc

[Travis Vitek <Tr...@roguewave.com>]

 

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

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?

Travis

Re: status of with gcc

[Martin Sebor <se...@roguewave.com>]

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

> 
> Travis
> 
>> Thanks
>> Martin
>>

RE: status of with gcc

[Travis Vitek <Tr...@roguewave.com>]

 

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.

Travis

>Thanks
>Martin
>