Merge pull request #4101 from MicrosoftDocs/main637963540524040213sync_temp

Repo sync for protected CLA branch

Author: colin-home

docs/c-runtime-library/crt-library-features.md

@@ -1,10 +1,10 @@
 ---
-title: "C runtime (CRT) and C++ Standard Library .lib files"
-description: "List of Microsoft C runtime and C++ Standard Library .lib files that you can link against and their associated compiler options and preprocessor directives."
+title: "C runtime (CRT) and C++ Standard Library (STL) .lib files"
+description: "List of Microsoft C runtime and C++ Standard Library (STL) .lib files that you can link against and their associated compiler options and preprocessor directives."
 ms.date: "3/5/2021"
 ms.topic: "reference"
 ms.custom: contperf-fy21q3
-helpviewer_keywords: ["MSVCR71.dll", "libraries [C++], multithreaded", "library files, run-time", "LIBCMT.lib", "LIBCP.lib", "LIBCPMT.lib", "run-time libraries, C", "CRT, release versions", "MSVCP71.dll", "LIBC.lib", "libraries [C++]", "libraries [C++], run-time", "linking [C++], libraries"]
+helpviewer_keywords: ["MSVCR71.dll", "libraries [C++], multithreaded", "library files, run-time", "LIBCMT.lib", "LIBCP.lib", "LIBCPMT.lib", "run-time libraries, C", "CRT, release versions", "MSVCP71.dll", "LIBC.lib", "libraries [C++]", "libraries [C++], run-time", "linking [C++], libraries", "STL libraries", "Microsoft standard template libraries"]
 ---
 # C runtime (CRT) and C++ Standard Library (STL) `.lib` files
 
@@ -14,6 +14,11 @@ See [Redistributing Visual C++ files](../windows/redistributing-visual-cpp-files
 
 See [C runtime library reference](../c-runtime-library/c-run-time-library-reference.md) if you're looking for API reference for the C runtime library.
 
+>[!NOTE]
+> Microsoft's implementation of the C++ Standard Library is often referred to as the *STL* or *Standard Template Library*. Although *C++ Standard Library* is the official name of the library as defined in ISO 14882, due to the popular use of "STL" and "Standard Template Library" in search engines, we occasionally use those names to make it easier to find our documentation.
+
+From a historical perspective, "STL" originally referred to the Standard Template Library written by Alexander Stepanov. Parts of that library were standardized in the C++ Standard Library, along with the ISO C runtime library, parts of the Boost library, and other functionality. Sometimes "STL" is used to refer to the containers and algorithms parts of the C++ Standard Library adapted from Stepanov's STL. In this documentation, Standard Template Library (STL) refers to the C++ Standard Library as a whole.
+
 ## C runtime `.lib` files
 
 The C runtime Library (CRT) is the part of the C++ Standard Library that incorporates the ISO C standard library. The Visual C++ libraries that implement the CRT support native code development, and both mixed native and managed code. All versions of the CRT support multi-threaded development. Most of the libraries support both static linking, to link the library directly into your code, or dynamic linking to let your code use common DLL files.
@@ -63,17 +68,17 @@ If you link your program from the command line without a compiler option that sp
 
 Using the statically linked CRT implies that any state information saved by the C runtime library will be local to that instance of the CRT. For example, if you use [`strtok`](../c-runtime-library/reference/strtok-strtok-l-wcstok-wcstok-l-mbstok-mbstok-l.md) when using a statically linked CRT, the position of the `strtok` parser is unrelated to the `strtok` state used in code in the same process (but in a different DLL or EXE) that is linked to another instance of the static CRT. In contrast, the dynamically linked CRT shares state for all code within a process that is dynamically linked to the CRT. This concern doesn't apply if you use the new more secure versions of these functions; for example, `strtok_s` doesn't have this problem.
 
-Because a DLL built by linking to a static CRT has its own CRT state, it isn't recommended to link statically to the CRT in a DLL unless the consequences of this are specifically desired and understood. For example, if you call [`_set_se_translator`](../c-runtime-library/reference/set-se-translator.md) in an executable that loads the DLL linked to its own static CRT, any hardware exceptions generated by the code in the DLL will not be caught by the translator, but hardware exceptions generated by code in the main executable will be caught.
+Because a DLL built by linking to a static CRT has its own CRT state, it isn't recommended to link statically to the CRT in a DLL unless the consequences of this are desired and understood. For example, if you call [`_set_se_translator`](../c-runtime-library/reference/set-se-translator.md) in an executable that loads the DLL linked to its own static CRT, any hardware exceptions generated by the code in the DLL won't be caught by the translator, but hardware exceptions generated by code in the main executable will be caught.
 
-If you're using the **`/clr`** compiler switch, your code will be linked with a static library, `msvcmrt.lib`. The static library provides a proxy between your managed code and the native CRT. You cannot use the statically linked CRT ( **`/MT`** or **`/MTd`** options) with **`/clr`**. Use the dynamically-linked libraries (**`/MD`** or **`/MDd`**) instead. The pure managed CRT libraries are deprecated in Visual Studio 2015 and unsupported in Visual Studio 2017.
+If you're using the **`/clr`** compiler switch, your code will be linked with a static library, `msvcmrt.lib`. The static library provides a proxy between your managed code and the native CRT. You can't use the statically linked CRT ( **`/MT`** or **`/MTd`** options) with **`/clr`**. Use the dynamically linked libraries (**`/MD`** or **`/MDd`**) instead. The pure managed CRT libraries are deprecated in Visual Studio 2015 and unsupported in Visual Studio 2017.
 
 For more information on using the CRT with **`/clr`**, see [Mixed (Native and Managed) Assemblies](../dotnet/mixed-native-and-managed-assemblies.md).
 
 To build a debug version of your application, the [`_DEBUG`](../c-runtime-library/debug.md) flag must be defined and the application must be linked with a debug version of one of these libraries. For more information about using the debug versions of the library files, see [CRT Debugging Techniques](/visualstudio/debugger/crt-debugging-techniques).
 
 This version of the CRT isn't fully conformant with the C99 standard. In versions before Visual Studio 2019 version 16.8, the `<tgmath.h>` header isn't supported. In all versions, the `CX_LIMITED_RANGE` and `FP_CONTRACT` pragma macros aren't supported. Certain elements such as the meaning of parameter specifiers in standard IO functions use legacy interpretations by default. You can use **`/Zc`** compiler conformance options and specify linker options to control some aspects of library conformance.
 
-## C++ Standard Library `.lib` files
+## C++ Standard Library (STL) `.lib` files
 
 | C++ Standard Library | Characteristics | Option | Preprocessor directives |
 |--|--|--|--|
@@ -92,9 +97,9 @@ For binary compatibility, more than one DLL file may be specified by a single im
 
 ## What problems exist if an application uses more than one CRT version?
 
-Every executable image (EXE or DLL) can have its own statically linked CRT, or can dynamically link to a CRT. The version of the CRT statically included in or dynamically loaded by a particular image depends on the version of the tools and libraries it was built with. A single process may load multiple EXE and DLL images, each with its own CRT. Each of those CRTs may use a different allocator, may have different internal structure layouts, and may use different storage arrangements. This means allocated memory, CRT resources, or classes passed across a DLL boundary can cause problems in memory management, internal static usage, or layout interpretation. For example, if a class is allocated in one DLL but passed to and deleted by another, which CRT deallocator is used? The errors caused can range from the subtle to the immediately fatal, and therefore direct transfer of such resources is strongly discouraged.
+Every executable image (EXE or DLL) can have its own statically linked CRT, or can dynamically link to a CRT. The version of the CRT statically included in or dynamically loaded by a particular image depends on the version of the tools and libraries it was built with. A single process may load multiple EXE and DLL images, each with its own CRT. Each of those CRTs may use a different allocator, may have different internal structure layouts, and may use different storage arrangements. This means allocated memory, CRT resources, or classes passed across a DLL boundary can cause problems in memory management, internal static usage, or layout interpretation. For example, if a class is allocated in one DLL but passed to and deleted by another, which CRT deallocator is used? The errors caused can range from the subtle to the immediately fatal, and therefore direct transfer of such resources is discouraged.
 
-You can avoid many of these issues by using Application Binary Interface (ABI) technologies instead, as they are designed to be stable and versionable. Design your DLL export interfaces to pass information by value, or to work on memory that is passed in by the caller rather than allocated locally and returned to the caller. Use marshaling techniques to copy structured data between executable images. Encapsulate resources locally and only allow manipulation through handles or functions you expose to clients.
+You can avoid many of these issues by using Application Binary Interface (ABI) technologies instead, as they're designed to be stable and versionable. Design your DLL export interfaces to pass information by value, or to work on memory that is passed in by the caller rather than allocated locally and returned to the caller. Use marshaling techniques to copy structured data between executable images. Encapsulate resources locally and only allow manipulation through handles or functions you expose to clients.
 
 It's also possible to avoid some of these issues if all of the images in your process use the same dynamically loaded version of the CRT. To ensure that all components use the same DLL version of the CRT, build them by using the **`/MD`** option, and use the same compiler toolset and property settings.