[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
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.
@@ -125,8 +125,18 @@
} // std
-#if defined(_WIN32) && !defined(cxx_EXPORTS)
-# define _LIBCPP_NEW_DELETE_VIS _LIBCPP_FUNC_VIS_ONLY
+ * 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)
+# define _LIBCPP_NEW_DELETE_VIS
# define _LIBCPP_NEW_DELETE_VIS _LIBCPP_FUNC_VIS
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 969 bytes
Desc: not available
More information about the cfe-commits