[PATCH] D25042: [libc++] Clarify _LIBCPP_NEW_DELETE_VIS for Windows

Shoaib Meenai via cfe-commits cfe-commits at lists.llvm.org
Wed Sep 28 13:44:56 PDT 2016

smeenai created this revision.
smeenai added reviewers: compnerd, EricWF, mclow.lists.
smeenai added a subscriber: cfe-commits.

Replace a stale reference to cxx_EXPORTS with _LIBCPP_BUILDING_LIBRARY,
and clarify why the operator new and delete family of functions are
marked dllexport when building but *not* dllimport when including the
header externally.

The new code is identical to the intent of the old code (and would be
functionally equivalent were cxx_EXPORTS still defined when building
libc++). The overall behavior is not ideal, since Microsoft's operator
new and delete functions will get called instead of libc++'s, but I
think consistently calling msvcrt's functions is better than either
calling msvcrt's or libc++'s functions depending on header inclusion.



Index: include/new
--- include/new
+++ include/new
@@ -125,8 +125,18 @@
 }  // std
-#if defined(_WIN32) && !defined(cxx_EXPORTS)
+ * NOTE: When using the Microsoft CRT, the operator new and delete
+ * family of functions are defined statically in msvcrt.lib. Marking
+ * them as dllimport in this header is therefore undesirable: if we were
+ * to mark them dllimport and then link against libc++, source files
+ * which included <new> would end up linking against libc++'s new and
+ * delete, while source files which did not include <new> would end up
+ * still linking against msvcrt's new, which would be a confusing and
+ * potentially error-prone inconsistency.
+ */
+#if defined(_LIBCPP_MSVCRT) && !defined(_LIBCPP_BUILDING_LIBRARY)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D25042.72889.patch
Type: text/x-patch
Size: 969 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20160928/16ab1b45/attachment.bin>

More information about the cfe-commits mailing list