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

[David Blaikie]

On May 2, 2013 6:53 AM, "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.

My understanding based on casual conversation (not committee
attendance/debate) was that user code was essentially told "don't do this"
and implementations were free to make more functions constexpr than the
standard requires at any time. Is that the case?

Are there other types of incompatibilities in C++14 so far? I assume so,
but just curious/checking.

>
> 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?

Presumably it should be keyed off the language spec preprocessor defines
provided by the compiler?

> 2.  How do clients override the default?

How much mismatch of library and language versions do you want to support.
Seems to me that could get out of hand quickly. I realize you're already
doing this for usages of libc++ with a compiler in c++98 mode, but the
multiplicative complexity might get out of hand quickly, no?

How does the implementation currently work to enable (or emulate) library
features when compiling in C++98 mode? I assume that solution won't scale
well to multiple versions? (And, as you mentioned, isn't built to actually
just do 98 style, unlike the future where you want to do pure 11,, rather
than anything from 14 that works with 11 language features)

Is there much value in allowing users to enable C++14 libraries when
compiling as C++11? Enough to justify the added complexity in the
implementation of having to consider which features are backwards
compatible and test them, etc?

> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20130502/72dd69f3/attachment.html>