[libcxx] r282644 - [libc++] Clarify _LIBCPP_NEW_DELETE_VIS for Windows
Shoaib Meenai via cfe-commits
cfe-commits at lists.llvm.org
Wed Sep 28 15:28:52 PDT 2016
Author: smeenai
Date: Wed Sep 28 17:28:51 2016
New Revision: 282644
URL: http://llvm.org/viewvc/llvm-project?rev=282644&view=rev
Log:
[libc++] Clarify _LIBCPP_NEW_DELETE_VIS for Windows
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.
Differential Revision: https://reviews.llvm.org/D25042
Modified:
libcxx/trunk/docs/DesignDocs/VisibilityMacros.rst
libcxx/trunk/include/new
Modified: libcxx/trunk/docs/DesignDocs/VisibilityMacros.rst
URL: http://llvm.org/viewvc/llvm-project/libcxx/trunk/docs/DesignDocs/VisibilityMacros.rst?rev=282644&r1=282643&r2=282644&view=diff
==============================================================================
--- libcxx/trunk/docs/DesignDocs/VisibilityMacros.rst (original)
+++ libcxx/trunk/docs/DesignDocs/VisibilityMacros.rst Wed Sep 28 17:28:51 2016
@@ -108,6 +108,19 @@ Visibility Macros
versioning namespace. This allows throwing and catching some exception types
between libc++ and libstdc++.
+**_LIBCPP_NEW_DELETE_VIS**
+ Mark a symbol as being exported by the libc++ library. This macro must be
+ applied to all `operator new` and `operator delete` overloads.
+
+ **Windows Behavior**: When using the Microsoft CRT, all the `operator new` and
+ `operator delete` overloads are defined statically in `msvcrt.lib`. Marking
+ them as `dllimport` in the libc++ `<new>` header is therefore undesirable: if
+ we were to mark them as `dllimport` and then link against libc++, source files
+ which included `<new>` would end up linking against libc++'s `operator new`
+ and `operator delete`, while source files which did not include `<new>` would
+ end up linking against msvcrt's `operator new` and `operator delete`, which
+ would be a confusing and potentially error-prone inconsistency.
+
Links
=====
Modified: libcxx/trunk/include/new
URL: http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/new?rev=282644&r1=282643&r2=282644&view=diff
==============================================================================
--- libcxx/trunk/include/new (original)
+++ libcxx/trunk/include/new Wed Sep 28 17:28:51 2016
@@ -125,8 +125,8 @@ _LIBCPP_FUNC_VIS new_handler get_new_han
} // std
-#if defined(_WIN32) && !defined(cxx_EXPORTS)
-# define _LIBCPP_NEW_DELETE_VIS _LIBCPP_FUNC_VIS_ONLY
+#if defined(_LIBCPP_MSVCRT) && !defined(_LIBCPP_BUILDING_LIBRARY)
+# define _LIBCPP_NEW_DELETE_VIS
#else
# define _LIBCPP_NEW_DELETE_VIS _LIBCPP_FUNC_VIS
#endif
More information about the cfe-commits
mailing list