Merge pull request #5596 from MicrosoftDocs/main

Albertyang0 · web-flow · commit 7570b420fa0b · 2024-06-14T01:29:48.000+08:00
6/13/2024 AM Publish
diff --git a/docs/build/reference/arch-arm64.md b/docs/build/reference/arch-arm64.md
@@ -22,12 +22,20 @@ Specifies the Armv9-A architecture, where **`x`** is a required extension value
 
 ## Remarks
 
-You may specify an ARM64 extension from Armv8.0-A through Armv8.9-A, and Armv9.0-A through Armv9.4-A. Optionally, enable one or more architecture features by appending a feature argument to the option<sup>3</sup>. For example, to target Armv8.0-A and enable feature `FEAT_LSE`, append feature argument **`lse`** so that the option becomes **`/arch:armv8.0+lse`**. For more information about available features and their requirements, see [`/feature` (ARM64)](feature-arm64.md)<sup>3</sup>.
+You can specify an ARM64 extension from Armv8.0-A through Armv8.9-A, and Armv9.0-A through Armv9.4-A. Optionally, enable one or more architecture features by appending a feature argument to the option<sup>3</sup>. For example, to target Armv8.0-A and enable feature `FEAT_LSE`, append feature argument **`lse`** so that the option becomes **`/arch:armv8.0+lse`**. For more information about available features and their requirements, see [`/feature` (ARM64)](feature-arm64.md)<sup>3</sup>.
 
 > [!NOTE]
 > Depending on your version of Visual Studio, the compiler may not yet generate instructions from all feature sets required by the extension level you specify. For example, **`/arch:armv8.1`** allows the `*Interlocked*` intrinsic functions to use the appropriate atomic instruction introduced with the Armv8.1-A extension feature `FEAT_LSE`, but compiler support requires Visual Studio 2022 version 17.2 or later.
 
-The `_M_ARM64` macro is defined by default when compiling for an ARM64 target. For more information, see [Predefined macros](../../preprocessor/predefined-macros.md).
+The `_M_ARM64` macro is defined by default when compiling for an ARM64 target. For more information, see [Predefined macros](../../preprocessor/predefined-macros.md)\
+
+The `__ARM_ARCH` macro is defined for `/arch:ARMv8.0` and higher. It indicates the ARM architecture extension level that the compiler is targeting. For more information, see [Predefined macros](../../preprocessor/predefined-macros.md).
+
+```cpp
+#if __ARM_ARCH >= 802
+    // code that requires ARMv8.2...
+#endif
+```
 
 **`/arch`** only affects code generation for native functions. When you use [`/clr`](clr-common-language-runtime-compilation.md) to compile, **`/arch`** has no effect on code generation for managed functions.
 
@@ -50,5 +58,6 @@ The `_M_ARM64` macro is defined by default when compiling for an ARM64 target. F
 ## See also
 
 [`/arch` (Minimum CPU architecture)](arch-minimum-cpu-architecture.md)\
+[Predefined macros](../../preprocessor/predefined-macros.md)\
 [MSVC compiler options](compiler-options.md)\
 [MSVC compiler command-line syntax](compiler-command-line-syntax.md)
diff --git a/docs/build/reference/link-repro-full-path-rsp.md b/docs/build/reference/link-repro-full-path-rsp.md
@@ -38,7 +38,7 @@ The linker produces `test.rsp` containing the following lines to reflect the ful
 
 ### To set this linker option programmatically
 
-- See <xref:Microsoft.VisualStudio.VCProjectEngine.VCLinkerTool.AssemblyDebug%2A>.
+- See [VCLinkerTool.AdditionalOptions](/dotnet/api/microsoft.visualstudio.vcprojectengine.vclinkertool.additionaloptions)
 
 ## See also
 
diff --git a/docs/build/reference/linker-options.md b/docs/build/reference/linker-options.md
@@ -1,7 +1,7 @@
 ---
 title: "MSVC Linker options"
 description: "A list of the options supported by the Microsoft LINK linker."
-ms.date: 06/03/2024
+ms.date: 06/10/2024
 f1_keywords: ["link"]
 helpviewer_keywords: ["linker [C++]", "linker [C++], options listed", "libraries [C++], linking to COFF", "LINK tool [C++], linker options"]
 ---
@@ -78,7 +78,7 @@ You can use the [`comment`](../../preprocessor/comment-c-cpp.md) pragma to speci
 | [`/LARGEADDRESSAWARE`](largeaddressaware-handle-large-addresses.md) | Tells the compiler that the application supports addresses larger than 2 gigabytes |
 | [`/LIBPATH`](libpath-additional-libpath.md) | Specifies a path to search before the environmental library path. |
 | [`/LINKREPRO`](linkrepro.md) | Specifies a path to generate link repro artifacts in. |
-| [`LINKREPROFULLPATHRSP`](link-repro-full-path-rsp.md) | Generates a response file containing the absolute paths to all the files that the linker took as input. |
+| [`/LINKREPROFULLPATHRSP`](link-repro-full-path-rsp.md) | Generates a response file containing the absolute paths to all the files that the linker took as input. |
 | [`/LINKREPROTARGET`](linkreprotarget.md) | Generates a link repro only when producing the specified target.<sup>16.1</sup> |
 | [`/LTCG`](ltcg-link-time-code-generation.md) | Specifies link-time code generation. |
 | [`/MACHINE`](machine-specify-target-platform.md) | Specifies the target platform. |
diff --git a/docs/build/toc.yml b/docs/build/toc.yml
@@ -640,8 +640,6 @@ items:
                   href: ../build/reference/kernel-create-kernel-mode-binary.md
                 - name: /link (Pass options to linker)
                   href: ../build/reference/link-pass-options-to-linker.md
-                - name: /LINKREPROFULLPATHRSP (Generate file containing absolute paths of linked files)
-                  href: ../build/reference/link-repro-full-path-rsp.md
                 - name: /LN (Create MSIL module)
                   href: ../build/reference/ln-create-msil-module.md
                 - name: /MD, /MT, /LD (Use Run-time library)
@@ -1027,6 +1025,8 @@ items:
               href: ../build/reference/libpath-additional-libpath.md
             - name: /LINKREPRO (Link repro directory name)
               href: ../build/reference/linkrepro.md
+            - name: /LINKREPROFULLPATHRSP (Generate file containing absolute paths of linked files)
+              href: ../build/reference/link-repro-full-path-rsp.md
             - name: /LINKREPROTARGET (Link repro file name)
               href: ../build/reference/linkreprotarget.md
             - name: /LTCG (Link-time code generation)
diff --git a/docs/cpp/casting.md b/docs/cpp/casting.md
@@ -1,34 +1,78 @@
 ---
-description: "Learn more about: Casting"
+description: "Learn more about: Casting in C++"
 title: "Casting"
-ms.date: "11/19/2018"
+ms.date: 6/11/2024
 helpviewer_keywords: ["casting [C++]", "coercion [C++]", "virtual functions [C++], in derived classes [C++]", "static cast operator", "dynamic cast operator", "polymorphic classes [C++]", "classes [C++], polymorphism"]
-ms.assetid: 3dbeb06e-2f4b-4693-832d-624bc8ec95de
+ai-usage: ai-assisted
 ---
 # Casting
 
-The C++ language provides that if a class is derived from a base class containing virtual functions, a pointer to that base class type can be used to call the implementations of the virtual functions residing in the derived class object. A class containing virtual functions is sometimes called a "polymorphic class."
+In C++, if a class is derived from a base class containing one or more virtual functions, a pointer to that base class type can be used to call virtual functions in the derived class object. A class containing virtual functions is sometimes called a "polymorphic class."
 
-Since a derived class completely contains the definitions of all the base classes from which it is derived, it is safe to cast a pointer up the class hierarchy to any of these base classes. Given a pointer to a base class, it might be safe to cast the pointer down the hierarchy. It is safe if the object being pointed to is actually of a type derived from the base class. In this case, the actual object is said to be the "complete object." The pointer to the base class is said to point to a "subobject" of the complete object. For example, consider the class hierarchy shown in the following figure.
-
-![Diagram of a class hierarchy where C derives from B, which derives from A.](../cpp/media/vc38zz1.gif "Class hierarchy") <br/>
+![Diagram of a class hierarchy where C derives from B, which derives from A.](../cpp/media/vc38zz1.gif "Class hierarchy")<br/>
 Class hierarchy
 
-An object of type `C` could be visualized as shown in the following figure.
+An object of type `C` can be visualized as follows:
 
 ![Diagram of Class C with subobjects B and A.](../cpp/media/vc38zz2.gif "Class C with subobjects B and A") <br/>
-Class C with sub-objects B and A
+Class C with subobjects B and A
 
-Given an instance of class `C`, there is a `B` subobject and an `A` subobject. The instance of `C`, including the `A` and `B` subobjects, is the "complete object."
+Given an instance of class `C`, there's a `B` subobject and an `A` subobject. The instance of `C`, including the `A` and `B` subobjects, is the "complete object."
 
-Using run-time type information, it is possible to check whether a pointer actually points to a complete object and can be safely cast to point to another object in its hierarchy. The [dynamic_cast](../cpp/dynamic-cast-operator.md) operator can be used to make these types of casts. It also performs the run-time check necessary to make the operation safe.
+Because a derived class completely contains the definitions of all the base classes from which it's derived, it's safe to cast a pointer to any of its base classes (also called an upcast). Given a pointer to a base class, it may be safe to cast the pointer to an instance of a derived class (also called a downcast).
 
-For conversion of nonpolymorphic types, you can use the [static_cast](../cpp/static-cast-operator.md) operator (this topic explains the difference between static and dynamic casting conversions, and when it is appropriate to use each).
+Using run-time type information, it's possible to check whether a pointer actually points to a complete object and can be safely cast to point to another object in its hierarchy. The [dynamic_cast](../cpp/dynamic-cast-operator.md) operator performs a run-time check to ensure that the operation is safe. It's better to design your class hierarchy so that you can use virtual functions to avoid the need for downcasting. However, if you must downcast, use `dynamic_cast` to ensure that the operation is safe.
 
-This section covers the following topics:
+For conversion of nonpolymorphic types, you can use the [static_cast](../cpp/static-cast-operator.md) operator (this topic explains the difference between static and dynamic casting conversions, and when it's appropriate to use each).
+
+The following example demonstrates the use of `dynamic_cast` and `static_cast`:
+
+```cpp
+#include <iostream>
+
+class Base {
+public:
+    virtual void print() { std::cout << "Base\n"; }
+};
+
+class Derived1 : public Base {
+public:
+    void print() override { std::cout << "Derived1\n"; }
+};
+
+class Derived2 : public Base {
+public:
+    void print() override { std::cout << "Derived2\n"; }
+};
 
-- [Casting operators](../cpp/casting-operators.md)
+class MostDerived : public Derived1, public Derived2 {
+public:
+    void print() override { std::cout << "MostDerived\n"; }
+};
+
+int main() {
+    MostDerived md;
+    Base* b1 = static_cast<Derived1*>(&md); // Upcast to Derived1 is safe
+    Base* b2 = static_cast<Derived2*>(&md); // Upcast to Derived2 is safe
+
+    // Downcast to MostDerived is ambiguous and unsafe
+    // MostDerived* md1 = static_cast<MostDerived*>(b1); // This won't compile
+    // MostDerived* md2 = static_cast<MostDerived*>(b2); // This won't compile
+
+    // Correct way to downcast in this situation
+    MostDerived* md1 = dynamic_cast<MostDerived*>(b1); // This is safe
+    MostDerived* md2 = dynamic_cast<MostDerived*>(b2); // This is safe
+
+    md1->print(); // Prints "MostDerived"
+    md2->print(); // Prints "MostDerived"
+
+    return 0;
+}
+```
+
+This section covers the following topics:
 
+- [Casting operators](../cpp/casting-operators.md)\
 - [Run-time type information](../cpp/run-time-type-information.md)
 
 ## See also
diff --git a/docs/cpp/data-type-ranges.md b/docs/cpp/data-type-ranges.md
@@ -3,31 +3,25 @@ description: "Learn more about: Data Type Ranges"
 title: "Data Type Ranges"
 ms.date: "05/28/2020"
 helpviewer_keywords: ["float keyword [C++]", "char keyword [C++]", "unsigned long", "__wchar_t keyword [C++]", "unsigned short int [C++]", "enum keyword [C++]", "unsigned char keyword [C++]", "integer data type [C++], data type ranges", "int data type", "data types [C++], ranges", "unsigned int [C++]", "short data type", "short int data", "signed types [C++], data type ranges", "long long keyword [C++]", "long double keyword [C++]", "double data type [C++], data type ranges", "signed short int [C++]", "unsigned short", "sized integer types", "signed int [C++]", "signed long int [C++]", "signed char keyword [C++]", "wchar_t keyword [C++]", "long keyword [C++]", "ranges [C++]", "unsigned types [C++], data type ranges", "floating-point numbers [C++]", "data type ranges", "ranges [C++], data types", "long int keyword [C++]", "unsigned long int [C++]"]
-ms.assetid: 3691ceca-05fb-4b82-b1ae-5c4618cda91a
 ---
 # Data Type Ranges
 
 The Microsoft C++ 32-bit and 64-bit compilers recognize the types in the table later in this article.
 
-- **`int`** (**`unsigned int`**)
+```cpp
+- int (unsigned int)
+- __int8 (unsigned __int8)
+- __int16 (unsigned __int16)
+- __int32 (unsigned __int32)
+- __int64 (unsigned __int64)
+- short (unsigned short)
+- long (unsigned long)
+- long long (unsigned long long)
+```
 
-- **`__int8`** (**`unsigned __int8`**)
+If its name begins with two underscores (`__`), the data type is nonstandard.
 
-- **`__int16`** (**`unsigned __int16`**)
-
-- **`__int32`** (**`unsigned __int32`**)
-
-- **`__int64`** (**`unsigned __int64`**)
-
-- **`short`** (**`unsigned short`**)
-
-- **`long`** (**`unsigned long`**)
-
-- **`long long`** (**`unsigned long long`**)
-
-If its name begins with two underscores (`__`), a data type is non-standard.
-
-The ranges that are specified in the following table are inclusive-inclusive.
+The ranges specified in the following table are inclusive-inclusive.
 
 |Type Name|Bytes|Other Names|Range of Values|
 |---------------|-----------|-----------------|---------------------|
@@ -52,16 +46,16 @@ The ranges that are specified in the following table are inclusive-inclusive.
 |**`long long`**|8|none (but equivalent to **`__int64`**)|-9,223,372,036,854,775,808 to 9,223,372,036,854,775,807|
 |**`unsigned long long`**|8|none (but equivalent to **`unsigned __int64`**)|0 to 18,446,744,073,709,551,615|
 |**`enum`**|varies|none| |
-|**`float`**|4|none|3.4E +/- 38 (7 digits)|
-|**`double`**|8|none|1.7E +/- 308 (15 digits)|
+|**`float`**|4|none|3.4E +/- 38 (seven digits)|
+|**`double`**|8|none|1.7E +/- 308 (fifteen digits)|
 |**`long double`**|same as **`double`**|none|Same as **`double`**|
 |**`wchar_t`**|2|**`__wchar_t`**|0 to 65,535|
 
-Depending on how it's used, a variable of **`__wchar_t`** designates either a wide-character type or multibyte-character type. Use the `L` prefix before a character or string constant to designate the wide-character-type constant.
+A variable of **`__wchar_t`** designates either a wide-character type or multibyte-character type. Use the `L` prefix before a character or string constant to designate the wide-character-type constant.
 
 **`signed`** and **`unsigned`** are modifiers that you can use with any integral type except **`bool`**. Note that **`char`**, **`signed char`**, and **`unsigned char`** are three distinct types for the purposes of mechanisms like overloading and templates.
 
-The **`int`** and **`unsigned int`** types have a size of four bytes. However, portable code should not depend on the size of **`int`** because the language standard allows this to be implementation-specific.
+The **`int`** and **`unsigned int`** types have a size of 4 bytes. However, portable code shouldn't depend on the size of **`int`** because the language standard allows this to be implementation-specific.
 
 C/C++ in Visual Studio also supports sized integer types. For more information, see [`__int8, __int16, __int32, __int64`](../cpp/int8-int16-int32-int64.md) and [Integer Limits](../cpp/integer-limits.md).
 
@@ -71,5 +65,5 @@ The range of enumerated types varies depending on the language context and speci
 
 ## See also
 
-[Keywords](../cpp/keywords-cpp.md)<br/>
+[Keywords](../cpp/keywords-cpp.md)\
 [Built-in types](../cpp/fundamental-types-cpp.md)
diff --git a/docs/error-messages/compiler-errors-1/compiler-error-c2055.md b/docs/error-messages/compiler-errors-1/compiler-error-c2055.md
@@ -1,22 +1,24 @@
 ---
-description: "Learn more about: Compiler Error C2055"
-title: "Compiler Error C2055"
-ms.date: "11/04/2016"
+description: "Learn more about: Microsoft Visual C++ compiler error C2055"
+title: "Compiler error C2055"
+ms.date: 06/10/2024
 f1_keywords: ["C2055"]
 helpviewer_keywords: ["C2055"]
-ms.assetid: 6cec79cc-6bec-443f-9897-fbf5452718c7
 ---
-# Compiler Error C2055
+# Compiler error C2055
 
-expected formal parameter list, not a type list
+> expected formal parameter list, not a type list
 
-A function definition contains a parameter type list instead of a formal parameter list. ANSI C requires formal parameters to be named unless they are void or an ellipsis (`...`).
+A function definition contains a parameter type list instead of a formal parameter list. ANSI C requires formal parameters to be named unless they're `void` or an ellipsis (`...`).
 
-The following sample generates C2055:
+An example of a named formal parameter is the `int i` in `void func(int i)`.\
+A parameter type list is a list of types, for example, `int, char`.
+
+The following code generates error `C2055`:
 
 ```c
 // C2055.c
 // compile with: /c
 void func(int, char) {}  // C2055
-void func (int i, char c) {}   // OK
+void func (int i, char c) {} // OK
 ```
diff --git a/docs/preprocessor/predefined-macros.md b/docs/preprocessor/predefined-macros.md
diff --git a/docs/standard-library/mutex-class-stl.md b/docs/standard-library/mutex-class-stl.md
