[cfe-dev] [libcxx] RFC: C++14 and beyond

Matthieu Monrocq matthieu.monrocq at gmail.com
Thu May 2 10:13:36 PDT 2013

On Thu, May 2, 2013 at 3:50 PM, Howard Hinnant <hhinnant at apple.com> wrote:

> libcxx was begun as a C++11 (then called C++0x) library.  It never even
> tried to adhere to the C++03 specification, though it does endeavor to work
> in C++03 language mode.
> Now we have a working draft for C++14 and certainly libc++ needs to
> support C++14.  However not all C++14 changes are 100% API compatible with
> C++11 (just like there are a few API breakages between C++03 and C++11).
>  For example John Spicer demonstrated the following example which shows
> that you can silently impact run time behavior by adding constexpr to a
> function.
> #if 0
> constexpr
> #endif
> int g(int) { return 1; }
> template <int I> struct A {};
> template <class T> auto f(T*) -> decltype(A<g(T())>())*;  // called if g
> is constexpr
> template <class T> int f(T);  // called if g is not constexpr
> int
> main()
> {
>     int *p = 0;
>     f(p);
> }
> This indicates that even the post-C++11 additions of constexpr to
> chrono::time_point and tuple have the potential to break code.
> This isn't an argument for not adding post-C++11 items to libc++.  It is
> simply an argument that we should provide a way for platforms and clients
> to choose:
> 1.  What is the default C++ standard libc++ is going to adhere to for a
> given platform?
> 2.  How do clients override the default?
> And I believe we should create a scalable solution beyond just the choice
> between C++11 and C++14.  C++17 is just around the corner.  And we should,
> at least for now, avoid macro names which allude to the numbers 14 and 17
> as there is no telling whether the committee will keep its schedule or not
> (it doesn't have a very good track record).
> I would like to open this topic up for discussion as I'm already aware of
> two post C++11 contributions that are blocked on this issue.
> Thanks,
> Howard
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev

Regarding the numbering... at the moment "C++14" are enabled in gcc by
using -std=c++1y (and I believe in Clang too), maybe using 1Y for now and
changing it to 14 (or 15) once the Standard is finalized would work ?

-- Matthieu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20130502/1a670a63/attachment.html>

More information about the cfe-dev mailing list