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

Howard Hinnant hhinnant at apple.com
Thu May 2 06:50:24 PDT 2013


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




More information about the cfe-dev mailing list