acrolinx

Author: TylerMSFT

docs/atl/reference/compiler-options-macros.md

@@ -5,7 +5,7 @@ ms.date: 02/01/2023
 f1_keywords: ["_ATL_ALL_WARNINGS", "_ATL_APARTMENT_THREADED", "_ATL_CSTRING_EXPLICIT_CONSTRUCTORS ", "_ATL_ENABLE_PTM_WARNING", "_ATL_FREE_THREADED", "_ATL_MODULES", "_ATL_MULTI_THREADED", "_ATL_NO_AUTOMATIC_NAMESPACE", "_ATL_NO_COM_SUPPORT", "ATL_NO_VTABLE", "ATL_NOINLINE", "_ATL_SINGLE_THREADED"]
 helpviewer_keywords: ["compiler options, macros"]
 ---
-# Compiler Options Macros
+# Compiler Options Macros acrolinx
 
 These macros control specific compiler features.
 

docs/cpp/cpp-bit-fields.md

@@ -14,7 +14,7 @@ Classes and structures can contain members that occupy less storage than an inte
 
 ## Remarks
 
-The (optional) *declarator* is the name by which the member is accessed in the program. It must be an integral type (including enumerated types). The *constant-expression* specifies the number of bits the member occupies in the structure. Anonymous bit fields — that is, bit-field members with no identifier — can be used for padding.
+The (optional) *declarator* is the name by which the member is accessed in the program. It must be an integral type (including enumerated types). The *constant-expression* specifies the number of bits the member occupies in the structure. Anonymous bit fields—that is, bit-field members with no identifier—can be used for padding.
 
 > [!NOTE]
 > An unnamed bit field of width 0 forces alignment of the next bit field to the next **type** boundary, where **type** is the type of the member.
@@ -35,14 +35,14 @@ struct Date {
 The conceptual memory layout of an object of type `Date` is shown in the following figure.
 
 :::image type="complex" source="../cpp/media/vc38uq1.png" alt-text="Memory layout of a date object, showing where the nWeekDay, nMonthDay, nMonth, and nYear bit fields fall.":::
-32 bits of memory are displayed in a row. The rightmost 3 bits are for nWeekDay. The next 6 bits to the left are for nMonthDay. The next 5 bits to the left are for nMonth. The next two bits are unused. The next 8 bits are for nYear. The remaining 8 bits to the left are unused.
+32 bits of memory are displayed in a row. Starting with the least significant bit, 3 bits are for nWeekDay. The next 6 bits are for nMonthDay. The next 5 bits are for nMonth. The next 2 bits are unused. The next 8 bits are for nYear. The remaining 8 bits are unused.
 :::image-end:::  
 
-Note that `nYear` is 8 bits long and would overflow the word boundary of the declared type, **`unsigned short`**. Therefore, it is begun at the beginning of a new **`unsigned short`**. It is not necessary that all bit fields fit in one object of the underlying type; new units of storage are allocated, according to the number of bits requested in the declaration.
+`nYear` is 8 bits long which would overflow the word boundary of the declared type, **`unsigned short`**. Therefore, it starts at the beginning of a new **`unsigned short`**. It isn't necessary that all bit fields fit in one object of the underlying type; new units of storage are allocated, according to the number of bits requested in the declaration.
 
 **Microsoft Specific**
 
-The ordering of data declared as bit fields is from low to high bit, as shown in the figure above.
+The ordering of data declared as bit fields is from low to high bit, as shown in the previous figure.
 
 **END Microsoft Specific**
 
@@ -63,12 +63,12 @@ struct Date {
 then the memory layout is as shown in the following figure:
 
 :::image type="complex" source="../cpp/media/vc38uq2.png" alt-text="Layout of a Date object with a zero length bit field, which forces alignment padding.":::
-64 bits of memory are displayed in a row. The rightmost 5 bits are for nMonth. The next 8 bits to the left are for nYear. The next 19 bits to the left are unused. The next 3 bits to the left are for nWeekDay. The next 6 bits to the left are for nMonthDay. The remaining bits to the left are unused.
+64 bits of memory are displayed in a row. Starting with the least significant bit, 5 bits are for nMonth. The next 8 bits are for nYear. The next 19 bits are unused. The next 3 bits are for nWeekDay. The next 6 bits are for nMonthDay. The remaining bits are unused.
 :::image-end:::  
 
 The underlying type of a bit field must be an integral type, as described in [Built-in types](../cpp/fundamental-types-cpp.md).
 
-If the initializer for a reference of type `const T&` is an lvalue that refers to a bit field of type `T`, the reference is not bound to the bit field directly. Instead, the reference is bound to a temporary initialized to hold the value of the bit field.
+If the initializer for a reference of type `const T&` is an lvalue that refers to a bit field of type `T`, the reference isn't bound to the bit field directly. Instead, the reference is bound to a temporary initialized to hold the value of the bit field.
 
 ## Restrictions on bit fields
 

docs/cpp/dynamic-cast-operator.md

@@ -19,15 +19,15 @@ dynamic_cast < type-id > ( expression )
 
 The `type-id` must be a pointer or a reference to a previously defined class type or a "pointer to void". The type of `expression` must be a pointer if `type-id` is a pointer, or an l-value if `type-id` is a reference.
 
-See [static_cast](../cpp/static-cast-operator.md) for an explanation of the difference between static and dynamic casting conversions, and when it is appropriate to use each.
+See [static_cast](../cpp/static-cast-operator.md) for an explanation of the difference between static and dynamic casting conversions, and when it's appropriate to use each.
 
 There are two breaking changes in the behavior of **`dynamic_cast`** in managed code:
 
-- **`dynamic_cast`** to a pointer to the underlying type of a boxed enum will fail at runtime, returning 0 instead of the converted pointer.
+- **`dynamic_cast`** to a pointer to the underlying type of a boxed enum fails at runtime, returning 0 instead of the converted pointer.
 
-- **`dynamic_cast`** will no longer throw an exception when `type-id` is an interior pointer to a value type, with the cast failing at runtime.  The cast will now return the 0 pointer value instead of throwing.
+- **`dynamic_cast`** won't throw an exception when `type-id` is an interior pointer to a value type; instead, the cast fails at runtime. The cast returns the 0 pointer value instead of throwing.
 
-If `type-id` is a pointer to an unambiguous accessible direct or indirect base class of `expression`, a pointer to the unique subobject of type `type-id` is the result. For example:
+If `type-id` is a pointer to an unambiguous accessible direct or indirect base class of `expression`; a pointer to the unique subobject of type `type-id` is the result. For example:
 
 ```cpp
 // dynamic_cast_1.cpp
@@ -44,7 +44,7 @@ void f(D* pd) {
 }
 ```
 
-This type of conversion is called an "upcast" because it moves a pointer up a class hierarchy, from a derived class to a class it is derived from. An upcast is an implicit conversion.
+This type of conversion is called an "upcast" because it moves a pointer up a class hierarchy, from a derived class to a class it's derived from. An upcast is an implicit conversion.
 
 If `type-id` is void*, a run-time check is made to determine the actual type of `expression`. The result is a pointer to the complete object pointed to by `expression`. For example:
 
@@ -65,7 +65,7 @@ void f() {
 }
 ```
 
-If `type-id` is not void*, a run-time check is made to see if the object pointed to by `expression` can be converted to the type pointed to by `type-id`.
+If `type-id` isn't `void*`, a run-time check is made to see if the object pointed to by `expression` can be converted to the type pointed to by `type-id`.
 
 If the type of `expression` is a base class of the type of `type-id`, a run-time check is made to see if `expression` actually points to a complete object of the type of `type-id`. If this is true, the result is a pointer to a complete object of the type of `type-id`. For example:
 
@@ -114,7 +114,7 @@ int main() {
 ```
 
 :::image type="complex" source="../cpp/media/vc39011.gif" alt-text="Class hierarchy that shows multiple inheritance.":::
-The diagram shows a class hierarchy with A as a base class of B which in turn is a base class of D. A is also a base class for C which in turn is a base class for D. Note that class D inherits from both B and C.
+The diagram shows a class hierarchy with A as a base class of B which is a base class of D. A is also a base class for C, which is a base class for D. Class D inherits from both B and C.
 :::image-end:::  
 
 A pointer to an object of type `D` can be safely cast to `B` or `C`. However, if `D` is cast to point to an `A` object, which instance of `A` would result? This would result in an ambiguous casting error. To get around this problem, you can perform two unambiguous casts. For example:
@@ -138,16 +138,16 @@ void f() {
 Further ambiguities can be introduced when you use virtual base classes. Consider the class hierarchy shown in the following figure.
 
 :::image type="complex" source="../cpp/media/vc39012.gif" alt-text="Class hierarchy that shows virtual base classes.":::
-The diagram shows the classes A, B, C, D, and E arranged as follows: Class A is a base class of B. Classes C and E each derive from B. Class E also inherits from D which inherits from class B which in turn inherits from class A.
+The diagram shows the classes A, B, C, D, and E arranged as follows: Class A is a base class of B. Classes C and E each derive from B. Class E also inherits from D, which inherits from class B which in turn inherits from class A.
 :::image-end:::  
 Class hierarchy that shows virtual base classes
 
-In this hierarchy, `A` is a virtual base class. Given an instance of class `E` and a pointer to the `A` subobject, a **`dynamic_cast`** to a pointer to `B` will fail due to ambiguity. You must first cast back to the complete `E` object, then work your way back up the hierarchy, in an unambiguous manner, to reach the correct `B` object.
+In this hierarchy, `A` is a virtual base class. Given an instance of class `E` and a pointer to the `A` subobject, a **`dynamic_cast`** to a pointer to `B` fails due to ambiguity. You must first cast back to the complete `E` object, then work your way back up the hierarchy, in an unambiguous manner, to reach the correct `B` object.
 
 Consider the class hierarchy shown in the following figure.
 
 :::image type="complex" source="../cpp/media/vc39013.gif" alt-text="Class hierarchy that shows duplicate base classes.":::
-The diagram shows the classes A, B, C, D, and E arranged as follows: Class B derives from Class A. Class C derives from class A. class D derives from class B. Class E derives from class C which derives from class A. In this case, the duplicate base class is class A which is directly or indirectly inherited by all the other classes. Class A is inherited directly by classes B and C, and indirectly by class D via class B, and indirectly by class E via class C, and indirectly in class D via class B.
+The diagram shows the classes A, B, C, D, and E arranged as follows: Class B derives from Class A. Class C derives from class A. class D derives from class B. Class E derives from class C which derives from class A. In this case, the duplicate base class is class A, which is directly or indirectly inherited by all the other classes. Class A is inherited directly by classes B and C, and indirectly by class D via class B, and indirectly by class E via class C, and indirectly in class D via class B.
 :::image-end:::  
 Class hierarchy that shows duplicate base classes
 
@@ -169,9 +169,9 @@ void f(D* pd) {
 }
 ```
 
-The **`dynamic_cast`** operator can also be used to perform a "cross cast." Using the same class hierarchy, it is possible to cast a pointer, for example, from the `B` subobject to the `D` subobject, as long as the complete object is of type `E`.
+The **`dynamic_cast`** operator can also be used to perform a "cross cast." Using the same class hierarchy, it's possible to cast a pointer, for example, from the `B` subobject to the `D` subobject, as long as the complete object is of type `E`.
 
-Considering cross casts, it is actually possible to do the conversion from a pointer to `D` to a pointer to the left-most `A` subobject in just two steps. You can perform a cross cast from `D` to `B`, then an implicit conversion from `B` to `A`. For example:
+Considering cross casts, it's possible to do the conversion from a pointer to `D` to a pointer to the left-most `A` subobject in just two steps. You can perform a cross cast from `D` to `B`, then an implicit conversion from `B` to `A`. For example:
 
 ```cpp
 // dynamic_cast_6.cpp
@@ -190,7 +190,7 @@ void f(D* pd) {
 
 A null pointer value is converted to the null pointer value of the destination type by **`dynamic_cast`**.
 
-When you use `dynamic_cast < type-id > ( expression )`, if `expression` cannot be safely converted to type `type-id`, the run-time check causes the cast to fail. For example:
+When you use `dynamic_cast < type-id > ( expression )`, if `expression` can't be safely converted to type `type-id`, the run-time check causes the cast to fail. For example:
 
 ```cpp
 // dynamic_cast_7.cpp
@@ -205,15 +205,15 @@ void f() {
 }
 ```
 
-The value of a failed cast to pointer type is the null pointer. A failed cast to reference type throws a [bad_cast Exception](../cpp/bad-cast-exception.md).   If `expression` does not point to or reference a valid object, a `__non_rtti_object` exception is thrown.
+The value of a failed cast to pointer type is the null pointer. A failed cast to reference type throws a [bad_cast Exception](../cpp/bad-cast-exception.md).   If `expression` doesn't point to or reference a valid object, a `__non_rtti_object` exception is thrown.
 
 See [typeid](../cpp/typeid-operator.md) for an explanation of the `__non_rtti_object` exception.
 
 ## Example
 
 The following sample creates the base class (struct A) pointer, to an object (struct C).  This, plus the fact there are virtual functions, enables runtime polymorphism.
 
-The sample also calls a non-virtual function in the hierarchy.
+The sample also calls a nonvirtual function in the hierarchy.
 
 ```cpp
 // dynamic_cast_8.cpp
@@ -274,7 +274,7 @@ int main() {
     C ConStack;
     Globaltest(ConStack);
 
-   // will fail because B knows nothing about C
+   // fails because B knows nothing about C
     B BonStack;
     Globaltest(BonStack);
 }

docs/cpp/friend-cpp.md

@@ -7,7 +7,7 @@ helpviewer_keywords: ["member access, from friend functions", "friend classes [C
 ---
 # `friend` (C++)
 
-In some circumstances, it's useful for a class to grant member-level access to functions that aren't members of the class, or to all members in a separate class. These free functions and classes are known as *friends*, marked by the **`friend`** keyword. Only the class implementer can declare who its friends are. A function or class can't declare itself as a friend of any class. In a class definition, use the **`friend`** keyword and the name of a non-member function or other class to grant it access to the private and protected members of your class. In a template definition, a type parameter can be declared as a **`friend`**.
+In some circumstances, it's useful for a class to grant member-level access to functions that aren't members of the class, or to all members in a separate class. These free functions and classes are known as *friends*, marked by the **`friend`** keyword. Only the class implementer can declare who its friends are. A function or class can't declare itself as a friend of any class. In a class definition, use the **`friend`** keyword and the name of a nonmember function or other class to grant it access to the private and protected members of your class. In a template definition, a type parameter can be declared as a **`friend`**.
 
 ## Syntax
 
@@ -224,8 +224,8 @@ Friendship isn't inherited, meaning that classes derived from `YourOtherClass` c
 
 The following figure shows four class declarations: `Base`, `Derived`, `aFriend`, and `anotherFriend`. Only class `aFriend` has direct access to the private members of `Base` (and to any members `Base` might have inherited).
 
-::image type="complex" source="../cpp/media/vc38v41.gif" alt-text="Diagram showing the derivation implications of a friend relationship.":::
-The diagram shows that class anotherFriend doesn't have a friend relationship with class base which friends class aFriend. Class aFriend is friended by class Base, but it doesn't have a friend relationship with class Derived even though class Derived inherits from Base, thus showing that inheritance doesn't imply the derived class has the same friends as the base class.
+:::image type="complex" source="../cpp/media/vc38v41.gif" alt-text="A diagram that shows the derivation implications of a friend relationship.":::
+The diagram shows that class anotherFriend doesn't have a friend relationship with class base which friends class aFriend. Class aFriend is friended by class Base, but it doesn't have a friend relationship with class Derived even though class Derived inherits from Base. This demonstrates that inheritance doesn't imply that the derived class has the same friends as the base class.
 :::image-end:::
 
 ## Inline `friend` definitions

docs/cpp/lvalues-and-rvalues-visual-cpp.md

@@ -13,19 +13,19 @@ The C++17 standard defines expression value categories as follows:
 - A *glvalue* is an expression whose evaluation determines the identity of an object, bit-field, or function.
 - A *prvalue* is an expression whose evaluation initializes an object or a bit-field, or computes the value of the operand of an operator, as specified by the context in which it appears.
 - An *xvalue* is a glvalue that denotes an object or bit-field whose resources can be reused (usually because it is near the end of its lifetime). Example: Certain kinds of expressions involving rvalue references (8.3.2) yield xvalues, such as a call to a function whose return type is an rvalue reference or a cast to an rvalue reference type.
-- An *lvalue* is a glvalue that is not an xvalue.
+- An *lvalue* is a glvalue that isn't an xvalue.
 - An *rvalue* is a prvalue or an xvalue.
 
 The following diagram illustrates the relationships between the categories:
 
 :::image type="complex" source="media/value_categories.png" alt-text="C++ expression value categories.":::
-The diagram begins with a box labeled expression, which has two children: glvalue and rvalue. glvalue has two children: lvalue and xvalue. rvalue has two children: prvalue, and it shares xvalue which is also a child of glvalue.
+The diagram begins with a box labeled expression, which has two children: glvalue and rvalue. glvalue has two children: lvalue and xvalue. rvalue has two children: prvalue, and it shares xvalue, which is also a child of glvalue.
 :::image-end:::  
 
 
 An lvalue has an address that your program can access. Examples of lvalue expressions include variable names, including **`const`** variables, array elements, function calls that return an lvalue reference, bit-fields, unions, and class members.
 
-A prvalue expression has no address that is accessible by your program. Examples of prvalue expressions include literals, function calls that return a non-reference type, and temporary objects that are created during expression evaluation but accessible only by the compiler.
+A prvalue expression has no address that is accessible by your program. Examples of prvalue expressions include literals, function calls that return a nonreference type, and temporary objects that are created during expression evaluation but accessible only by the compiler.
 
 An xvalue expression has an address that no longer accessible by your program but can be used to initialize an rvalue reference, which provides access to the expression. Examples include function calls that return an rvalue reference, and the array subscript, member and pointer to member expressions where the array or object is an rvalue reference.