
<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div><blockquote type="cite" class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class=""><div class="h5"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class=""><div class=""><div class="">These new declarations should be wrapped in a version check; we should only declare them in <new> if we're in C++14 or later.</div></div></div></div></div></div></blockquote><div class=""><br class=""></div></div></div><div class="">Clang also supports the -fsized-deallocation flag in C++11 mode. Should we factor this in the version check as well, or perhaps</div><div class="">remove/deprecate it from Clang?</div></div></div></div></blockquote><div class=""><br class=""></div><div class="">I don't think there's any need to care about whether the feature is enabled in Clang. The non-nothrow forms are implicitly declared by the compiler, so libc++'s declarations are redundant in all modes (but technically the standard says they should be there in <new> in C++14, so I suppose we should include them for completeness). The nothrow forms are useless and never implicitly called, but we're (currently; I have filed a library issue) required to provide them.</div><div class=""><br class=""></div><div class="">So I think you should just check whether libc++ is in C++14 mode, and declare these functions if so.</div></div></div></div></blockquote><br class=""></div><div>There’s a whole set of deployment issues that we need to deal with here; none of which apply to people who build libc++ for their own use.</div><div><br class=""></div><div>Here’s a couple, using Mac OS as an example - but the same thing applies to FreeBSD (and others).</div><div><br class=""></div><div>1) Apple ships an update to Xcode that contains the changes to <new>, but not an updated dylib (because the dev tools and system libraries are shipped in different vehicles). Does this mean that you can build an app that will not run because the dylib is missing calls?</div><div><br class=""></div><div>2) Apple ships (say) 10.11.0 with an updated dylib. A developer builds and tests his app with this, and puts it on the app store. A user purchases the app, only to find that it doesn’t run on his (10.10) system.</div><div><br class=""></div><div>— Marshall</div><div><br class=""></div></body></html>