[cfe-dev] Libc++ Windows Semi-analyzed test results

[Ruben Van Boxem]

2011/9/28 Marc Glisse <marc.glisse at inria.fr>

> On Wed, 28 Sep 2011, Howard Hinnant wrote:
>
>  #include <iostream>
>>
>> int main()
>> {
>>   std::cout << __cplusplus << '\n';
>> }
>>
>> Without -std=c++0x:
>>
>> 1
>>
>> With -std=c++0x:
>>
>> 201103
>>
>
> NOOOOOOOO!!!
> :-(
>
> What is the rational for defining it before the C++11 support is (almost)
> complete? The main point of the value of this macro is imho to be able to
> detect whether we can use C++11 features. If you want to indicate
> experimental partial support, a compiler specific macro is fine. But
> defining __cplusplus to 201103 when the new standard isn't implemented yet
> makes the macro useless. The only rational I could think of is that the
> C++11 mode of clang is considered experimental and unsupported and thus it
> doesn't matter that it doesn't work...
>
> As a (header) library writer who wants to use C++11 features if possible,
> my choices are __cplusplus or version tests on all the compilers I can get
> my hands on. You can guess which one I prefer.
>
> I'm sure there was a good reason for setting the new value and I'd like to
> hear it... (this discussion probably should have taken place on the
> reflectors to get the vendors to agree on a strategy)
>

Clang has the __has_feature macros to detect if anything is present or
missing, exactly for this purpose. Libc++ is as far as I know feature
complete, only missing <atomic> support, which is in active development.

The reason I like that the macro is defined, is that things like the uchar.h
header can use it to see if char16_t/char32_t are builting types, or if it
is safe/better to typedef them. This is impossible with GCC, which made the
required ifdef... very lengthy.

Ruben


>
> --
> Marc Glisse
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20110928/20ee4043/attachment.html>