Merge pull request #4837 from MicrosoftDocs/main638373115079393557sync_temp

For protected branch, push strategy should use PR and merge to target branch method to work around git push error

Author: learn-build-service-prod[bot]

docs/error-messages/compiler-warnings/compiler-warning-level-1-c4251.md

@@ -1,40 +1,73 @@
 ---
 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
 
 > '*type*' : class '*type1*' needs to have dll-interface to be used by clients of class '*type2*'
 
 ## 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 <vector>
+ 
+class __declspec(dllexport) X
+{
+public:
+    X();
+    ~X();
+ 
+    void do_something();
+ 
+private:
+    void do_something_else();
+    std::vector<int> 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 <vector>
-using namespace std;
-class Node;
-class __declspec(dllexport) VecWrapper : vector<Node *> {};   // C4251
+ 
+class X
+{
+public:
+    __declspec(dllexport) X();
+    __declspec(dllexport) ~X();
+ 
+    __declspec(dllexport) void do_something();
+ 
+private:
+    void do_something_else();
+    std::vector<int> data;
+};
 ```

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 (`<EnableASAN>`) 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 `<EnableASAN>` 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 (`<EnableASAN>`) is shown, the build doesn't honor it. That's because the custom *`.props`* files get included after *`Microsoft.cpp.props`*, which uses the `<EnableASAN>` 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 `<EnableASAN>` property. For more information, see [Customize C++ builds](/visualstudio/msbuild/customize-your-build#customize-c-builds).