This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Macro for C++14 support
- From: Jonathan Wakely <jwakely dot gcc at gmail dot com>
- To: Paolo Carlini <paolo dot carlini at oracle dot com>
- Cc: Gabriel Dos Reis <gdr at integrable-solutions dot net>, "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Tue, 23 Apr 2013 15:47:27 +0100
- Subject: Re: Macro for C++14 support
- References: <CAH6eHdRC=1+VFUDFrt7kjFTy9QkTNB9tQB95-AUNMyKOyKkM+A at mail dot gmail dot com> <CAAiZkiBQxNS33H0uEgZfRTY0kBEgyc7+hCzeXw-V+KGiEka1mQ at mail dot gmail dot com> <007d1aea-9f40-4324-9db2-3c1d4fd3ccb7 at email dot android dot com>
On 23 April 2013 15:29, Paolo Carlini wrote:
> Hi,
>
> Gabriel Dos Reis <gdr@integrable-solutions.net> ha scritto:
>
>>There appear to be two targets: C++14 and C++17. Personally, I am
>>inclined
>>to have CXX14 and CXX1Y, where CXX1Y is for the presumed C++17 target.
>
> This clarified - thanks - I'm wondering if it's safe to assume that the C++14 library is a superset of the C++11 one: in that case passing -std=c++14 would also automatically define the C++11 macro and I see a tiny front-end patch going in followed by smooth progress in library. Otherwise - if -std=c++14 does *not* automatically define the C++11 macro too - we also need a ton of boring changes in the library, where things become wrapped in C++11 macro || C++14 macro. Did I explain myself clearly enough?
If the ~thread motion, N3636, passed then the C++11 and C++14
libraries are incompatible.
N3657 adds new member function overloads to existing library types,
but should do so in a backward-compatible way (that was the point of
the final revision of Joaquin's paper.)
But remember we no longer use __GXX_EXPERIMENTAL_CXX0X__ anyway, we
check __cplusplus >= 201103L, and so within those chunks we could
additionally check for some C++14 macro.