diff --git a/docs/error-messages/compiler-warnings/compiler-warning-level-1-c4251.md b/docs/error-messages/compiler-warnings/compiler-warning-level-1-c4251.md index b47e246b650..1b8f1fb7e35 100644 --- a/docs/error-messages/compiler-warnings/compiler-warning-level-1-c4251.md +++ b/docs/error-messages/compiler-warnings/compiler-warning-level-1-c4251.md @@ -1,10 +1,9 @@ --- description: "Learn more about: Compiler Warning (level 1) C4251" title: "Compiler Warning (level 1) C4251" -ms.date: 02/22/2022 +ms.date: 12/01/2023 f1_keywords: ["C4251"] helpviewer_keywords: ["C4251"] -ms.assetid: a9992038-f0c2-4fc4-a9be-4509442cbc1e --- # Compiler Warning (level 1) C4251 @@ -12,29 +11,63 @@ ms.assetid: a9992038-f0c2-4fc4-a9be-4509442cbc1e ## Remarks +This warning happens if a class is marked with `__declspec(dllexport)` or `__declspec(dllimport)` and a nonstatic data member that is a member of the class or a member of one of its base classes, has a type that is a class type that isn't marked with `__declspec(dllexport)` or `__declspec(dllimport)`. See [Example](#example). + To minimize the possibility of data corruption when exporting a class declared as [`__declspec(dllexport)`](../../cpp/dllexport-dllimport.md), ensure that: - All your static data is accessed through functions that are exported from the DLL. - - No inlined methods of your class can modify static data. - - No inlined methods of your class use CRT functions or other library functions that use static data. For more information, see [Potential errors passing CRT objects across DLL boundaries](../../c-runtime-library/potential-errors-passing-crt-objects-across-dll-boundaries.md). - - No methods of your class (whether inlined or not) can use types where the instantiation in the EXE and DLL have static data differences. -You can avoid issues when exporting a class from a DLL: Define your class to have virtual functions, a virtual destructor, and functions to instantiate and delete objects of the type. You can then just call virtual functions on the type. +You can avoid issues when exporting a class from a DLL by: -C4251 can be ignored if your class is derived from a type in the C++ Standard Library, you're compiling a debug release (**`/MTd`**), and where the compiler error message refers to `_Container_base`. +- Defining your class to have virtual functions. +- Defining a virtual destructor. +- Defining functions to instantiate and delete instances of the type. -## Example +You can ignore C4251 if your class is derived from a type in the C++ Standard Library, you're compiling a debug release (**`/MTd`**), and the compiler error message refers to `_Container_base`. + +Think carefully about adding `__declspec(dllexport)` or `__declspec(dllimport)` to a class because it's almost always not the right choice and it can make maintenance more difficult because it makes changing implementation details harder. -This sample exports a specialized class `VecWrapper` derived from `std::vector`. +## Example ```cpp // C4251.cpp -// compile with: /EHsc /MTd /W2 /c +// Compile with /std:c++20 /EHsc /W2 /c C4251.cpp +#include + +class __declspec(dllexport) X +{ +public: + X(); + ~X(); + + void do_something(); + +private: + void do_something_else(); + std::vector data; // warning c4251 +}; +``` + +To fix this warning, don't mark the class with `__declspec(dllexport)` or `__declspec(dllimport)`. Instead, only mark the methods that are used directly by a client. For example: + +```cpp +// C4251_fixed.cpp +// Compile with /std:c++20 /EHsc /W2 /c C4251-fixed.cpp #include -using namespace std; -class Node; -class __declspec(dllexport) VecWrapper : vector {}; // C4251 + +class X +{ +public: + __declspec(dllexport) X(); + __declspec(dllexport) ~X(); + + __declspec(dllexport) void do_something(); + +private: + void do_something_else(); + std::vector data; +}; ``` diff --git a/docs/sanitizers/asan-known-issues.md b/docs/sanitizers/asan-known-issues.md index da50d277f3b..cbf822f6b87 100644 --- a/docs/sanitizers/asan-known-issues.md +++ b/docs/sanitizers/asan-known-issues.md @@ -1,7 +1,7 @@ --- title: "AddressSanitizer known issues" description: "Technical description of the AddressSanitizer for Microsoft C/C++ known issues." -ms.date: 04/15/2022 +ms.date: 12/1/2023 helpviewer_keywords: ["AddressSanitizer known issues"] --- @@ -23,10 +23,11 @@ These options and functionality are incompatible with [`/fsanitize=address`](../ - [C++ AMP](../parallel/amp/cpp-amp-overview.md) is unsupported, and should be disabled. - [Universal Windows Platform](../cppcx/universal-windows-apps-cpp.md) (UWP) applications are unsupported. - [Special case list](https://clang.llvm.org/docs/SanitizerSpecialCaseList.html) files are unsupported. +- [MFC](../mfc/mfc-concepts.md) using the optional [`alloc_dealloc_mismatch`](error-alloc-dealloc-mismatch.md) runtime option is unsupported. ## Standard library support -The MSVC standard library (STL) is partially enlightened to understand the AddressSanitizer and provide additional checks. For more information, see [container-overflow error](./error-container-overflow.md). +The MSVC standard library (STL) is partially enlightened to understand the AddressSanitizer and provide other checks. For more information, see [container-overflow error](./error-container-overflow.md). When annotations are disabled or in versions without support, AddressSanitizer exceptions raised in STL code do still identify true bugs. However, they aren't as precise as they could be. @@ -56,7 +57,7 @@ int main() { ## Windows versions -As there are dependencies with specific Windows versions, support is focused on Windows 10. MSVC AddressSanitizer was tested on 10.0.14393 (RS1), and 10.0.21323 (pre-release insider build). [Report a bug](https://aka.ms/feedback/report?space=62) if you run into issues. +As there are dependencies with specific Windows versions, support is focused on Windows 10. MSVC AddressSanitizer was tested on 10.0.14393 (RS1), and 10.0.21323 (prerelease insider build). [Report a bug](https://aka.ms/feedback/report?space=62) if you run into issues. ## Memory usage @@ -68,7 +69,7 @@ The *`clang_rt.asan*.dll`* runtime files are installed next to the compilers in ## Custom property sheet support -The Property Manager window in the Visual Studio IDE allows you to add custom *`.props`* files to your projects. Even though the **Enable Address Sanitizer** property (``) is shown, it's not honored by the build. That's because the custom *`.props`* files get included after *`Microsoft.cpp.props`*, which uses the `` value to set other properties. +The Property Manager window in the Visual Studio IDE allows you to add custom *`.props`* files to your projects. Even though the **Enable Address Sanitizer** property (``) is shown, the build doesn't honor it. That's because the custom *`.props`* files get included after *`Microsoft.cpp.props`*, which uses the `` value to set other properties. As a workaround, you can create a *`Directory.Build.props`* file in the root of your project to define the `` property. For more information, see [Customize C++ builds](/visualstudio/msbuild/customize-your-build#customize-c-builds).