<p dir="ltr"><br>
On May 2, 2013 6:53 AM, "Howard Hinnant" <<a href="mailto:hhinnant@apple.com">hhinnant@apple.com</a>> wrote:<br>
><br>
> 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.<br>
><br>
> 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.<br>

><br>
> #if 0<br>
> constexpr<br>
> #endif<br>
> int g(int) { return 1; }<br>
><br>
> template <int I> struct A {};<br>
><br>
> template <class T> auto f(T*) -> decltype(A<g(T())>())*;  // called if g is constexpr<br>
> template <class T> int f(T);  // called if g is not constexpr<br>
><br>
> int<br>
> main()<br>
> {<br>
>     int *p = 0;<br>
>     f(p);<br>
> }<br>
><br>
> This indicates that even the post-C++11 additions of constexpr to chrono::time_point and tuple have the potential to break code.</p>
<p dir="ltr">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?</p>

<p dir="ltr">Are there other types of incompatibilities in C++14 so far? I assume so, but just curious/checking.</p>
<p dir="ltr">><br>
> 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:<br>
><br>
> 1.  What is the default C++ standard libc++ is going to adhere to for a given platform?</p>
<p dir="ltr">Presumably it should be keyed off the language spec preprocessor defines provided by the compiler?</p>
<p dir="ltr">> 2.  How do clients override the default?</p>
<p dir="ltr">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?</p>

<p dir="ltr">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)</p>

<p dir="ltr">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?</p>

<p dir="ltr">> 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).<br>

><br>
> 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.<br>
><br>
> Thanks,<br>
> Howard<br>
><br>
> _______________________________________________<br>
> cfe-dev mailing list<br>
> <a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br>
> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
</p>