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

[Larisse Voufo]

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


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

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