[libcxx] r229281 - Implement C++14's sized deallocation functions, since there are no longer implicitly defined by clang, as of r229241.

Larisse Voufo lvoufo at google.com
Tue Feb 17 15:52:44 PST 2015

Please see http://reviews.llvm.org/D7707.

On Tue, Feb 17, 2015 at 7:22 AM, Marshall Clow <mclow.lists at gmail.com>

> 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.
>> Clang also supports the -fsized-deallocation flag in C++11 mode. Should
>> we factor this in the version check as well, or perhaps
>> remove/deprecate it from Clang?
> 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.
> So I think you should just check whether libc++ is in C++14 mode, and
> declare these functions if so.
> 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.
> Here’s a couple, using Mac OS as an example - but the same thing applies
> to FreeBSD (and others).
> 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?
> 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.
> — Marshall
> _______________________________________________
> cfe-commits mailing list
> cfe-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20150217/ed324baf/attachment.html>

More information about the cfe-commits mailing list