[cfe-dev] [libcxx] RFC: C++14 and beyond
Howard Hinnant
hhinnant at apple.com
Tue May 7 11:56:08 PDT 2013
On May 7, 2013, at 2:52 PM, Richard Smith <richard at metafoo.co.uk> wrote:
> On Tue, May 7, 2013 at 11:37 AM, Howard Hinnant <hhinnant at apple.com> wrote:
> So I'm thinking along these lines in <__config>, below where platforms customize things:
>
> #ifndef _LIBCPP_STD_VER
> # if 1 // -std=c++98/03/11
> # define _LIBCPP_STD_VER 11
> # elif 0 // -std=c++1y/14
> # define _LIBCPP_STD_VER 13 // current year, or date of std ratification
> # elif 0 // -std=c++17
> // ...
> # endif
> #endif // _LIBCPP_STD_VER
>
> I can't make this work today because I can't tell the difference between -std=c++98/03/11 and -std=c++1y/14.
>
> If the client (or platform) desires, they can #define _LIBCPP_STD_VER and to whatever they want and <__config> will respect their definition.
>
> libcxx implementors can:
>
> #if _LIBCPP_STD_VER > 11
>
> // implement a post C++11 feature
>
> #endif
>
> The clang driver could be taught how to set _LIBCPP_STD_VER.
>
> Thoughts? Help on telling the difference between -std=c++98/03/11 and -std=c++1y/14?
>
> There's been some discussion on the -admin reflector about what value we should use for __cplusplus, but it didn't reach anything that looked like consensus. How about we use 201305L (ie, now) as the value for __cplusplus for our c++1y mode for the 3.3 release, and you key off __cplusplus > 201103L ?
That sounds fine with me. If there's any political problems with that, using a "throw away" macro (e.g. __experimental_1y, _MAKE_HOWARD_HAPPY) or whatever would be fine too. :-) libcxx can adapt to changing clangs.
Thanks,
Howard
More information about the cfe-dev
mailing list