[patch] libstdc++/65473 Make <ciso646> define libstdc++ version macros.

Jonathan Wakely jwakely@redhat.com
Fri Sep 4 09:28:00 GMT 2015


On 03/09/15 13:22 -0600, Martin Sebor wrote:
>On 09/03/2015 04:58 AM, Jonathan Wakely wrote:
>>This change would allow including <ciso646> to be used to check for
>>__GLIBCXX__ and detect whether youre using libstdc++ or not. Howard
>>Hinnant recommends including that header for libc++ because it has no
>>other effects in C++.
>>
>>We could make every <cxxx> header include <bits/c++config.h> so that
>>any of them can be used, but I can't be bothered doing that change!
>>This makes it work for the one header that is recommended to be used,
>>but of course that doesn't help people using older versions of
>>libstdc++, who still need to include some other header.
>>
>>Is this worth doing?
>
>I'd say it's worth doing consistently, in every header. Users are
>told by others (e.g., on various discussion forums) to expect to
>be able to check what C++ library implementation they're using by
>including any C++ standard header and testing the known version
>macros.

OK, here's a patch to add <bits/c++config.h> to all the <cxxx> headers
that don't have it.

Tested powerpc64le-linux, committed to trunk.

I must admit I don't understand why many of the <cxxx> headers
include the <xxx.h> header and <bits/c++config.h> outside the include
guard ... AFAIK it's only needed for <assert.h>, and will lead to
<cxxx> headers being unnecessarily re-opened if included twice, but
I'm not going to change that.


>  <cuchar>             <stdin>:1:18: fatal error: cuchar: No such file 
>or directory
>compilation terminated.
>0

Ed sent a patch to add <cuchar> which I'm going to tidy up and commit.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch.txt
Type: text/x-patch
Size: 6606 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20150904/e39b0dbb/attachment.bin>


More information about the Gcc-patches mailing list