> 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 [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
