format cpp pr5

Author: mtx48109

docs/cpp/how-to-create-and-use-weak-ptr-instances.md

@@ -13,7 +13,7 @@ ms.workload: ["cplusplus"]
 # How to: Create and Use weak_ptr Instances
 Sometimes an object must store a way to access the underlying object of a `shared_ptr` without causing the reference count to be incremented. Typically, this situation occurs when you have cyclic references between `shared_ptr` instances.  
 
- The best design is to avoid shared ownership of pointers whenever you can. However, if you must have shared ownership of `shared_ptr` instances, avoid cyclic references between them. When cyclic references are unavoidable, or even preferable for some reason, use `weak_ptr` to give one or more of the owners a weak reference to another `shared_ptr`. By using a `weak_ptr`, you can create a `shared_ptr` that joins to an existing set of related instances, but only if the underlying memory resource is still valid. A `weak_ptr` itself does not participate in the reference counting, and therefore, it cannot prevent the reference count from going to zero. However, you can use a `weak_ptr` to try to obtain a new copy of the `shared_ptr` with which it was initialized. If the memory has already been deleted, a **bad_weak_ptr** exception is thrown. If the memory is still valid, the new shared pointer increments the reference count and guarantees that the memory will be valid as long as the `shared_ptr` variable stays in scope.  
+ The best design is to avoid shared ownership of pointers whenever you can. However, if you must have shared ownership of `shared_ptr` instances, avoid cyclic references between them. When cyclic references are unavoidable, or even preferable for some reason, use `weak_ptr` to give one or more of the owners a weak reference to another `shared_ptr`. By using a `weak_ptr`, you can create a `shared_ptr` that joins to an existing set of related instances, but only if the underlying memory resource is still valid. A `weak_ptr` itself does not participate in the reference counting, and therefore, it cannot prevent the reference count from going to zero. However, you can use a `weak_ptr` to try to obtain a new copy of the `shared_ptr` with which it was initialized. If the memory has already been deleted, a `bad_weak_ptr` exception is thrown. If the memory is still valid, the new shared pointer increments the reference count and guarantees that the memory will be valid as long as the `shared_ptr` variable stays in scope.  
 
 ## Example  
  The following code example shows a case where `weak_ptr` is used to ensure proper deletion of objects that have circular dependencies. As you examine the example, assume that it was created only after alternative solutions were considered. The `Controller` objects represent some aspect of a machine process, and they operate independently. Each controller must be able to query the status of the other controllers at any time, and each one contains a private `vector<weak_ptr<Controller>>` for this purpose. Each vector contains a circular reference, and therefore, `weak_ptr` instances are used instead of `shared_ptr`.  

docs/cpp/how-to-design-for-exception-safety.md

@@ -81,7 +81,7 @@ public:
 ```  
   
 ### Use the RAII Idiom to Manage Resources  
- To be exception-safe, a function must ensure that objects that it has allocated by using `malloc` or `new` are destroyed, and all resources such as file handles are closed or released even if an exception is thrown. The *Resource Acquisition Is Initialization* (RAII) idiom ties management of such resources to the lifespan of automatic variables. When a function goes out of scope, either by returning normally or because of an exception, the destructors for all fully-constructed automatic variables are invoked. An RAII wrapper object such as a smart pointer calls the appropriate delete or close function in its destructor. In exception-safe code, it is critically important to pass ownership of each resource immediately to some kind of RAII object. Note that the `vector`, `string`, `make_shared`, `fstream`, and similar classes handle acquisition of the resource for you.  However, `unique_ptr` and traditional `shared_ptr` constructions are special because resource acquisition is performed by the user instead of the object; therefore, they count as *Resource Release Is Destruction* but are questionable as RAII.  
+ To be exception-safe, a function must ensure that objects that it has allocated by using `malloc` or **new** are destroyed, and all resources such as file handles are closed or released even if an exception is thrown. The *Resource Acquisition Is Initialization* (RAII) idiom ties management of such resources to the lifespan of automatic variables. When a function goes out of scope, either by returning normally or because of an exception, the destructors for all fully-constructed automatic variables are invoked. An RAII wrapper object such as a smart pointer calls the appropriate delete or close function in its destructor. In exception-safe code, it is critically important to pass ownership of each resource immediately to some kind of RAII object. Note that the `vector`, `string`, `make_shared`, `fstream`, and similar classes handle acquisition of the resource for you.  However, `unique_ptr` and traditional `shared_ptr` constructions are special because resource acquisition is performed by the user instead of the object; therefore, they count as *Resource Release Is Destruction* but are questionable as RAII.  
   
 ## The Three Exception Guarantees  
  Typically, exception safety is discussed in terms of the three exception guarantees that a function can provide: the *no-fail guarantee*, the *strong guarantee*, and the *basic guarantee*.  

docs/cpp/how-to-interface-between-exceptional-and-non-exceptional-code.md

@@ -188,7 +188,7 @@ BOOL DiffFiles2(const string& file1, const string& file2)
 
 ```  
   
- When you convert from exceptions to error codes, one potential issue is that error codes often don't contain the richness of information that an exception can store. To address this, you can provide a `catch` block for each specific exception type that might be thrown, and perform logging to record the details of the exception before it is converted to an error code. This approach can create a lot of code repetition if multiple functions all use the same set of `catch` blocks. A good way to avoid code repetition is by refactoring those blocks into one private utility function that implements the `try` and `catch` blocks and accepts a function object that is invoked in the `try` block. In each public function, pass the code to the utility function as a lambda expression.  
+ When you convert from exceptions to error codes, one potential issue is that error codes often don't contain the richness of information that an exception can store. To address this, you can provide a **catch** block for each specific exception type that might be thrown, and perform logging to record the details of the exception before it is converted to an error code. This approach can create a lot of code repetition if multiple functions all use the same set of **catch** blocks. A good way to avoid code repetition is by refactoring those blocks into one private utility function that implements the **try** and **catch** blocks and accepts a function object that is invoked in the **try** block. In each public function, pass the code to the utility function as a lambda expression.  
   
 ```cpp  
 template<typename Func>   

docs/cpp/identifiers-cpp.md

@@ -88,7 +88,7 @@ int main() {
 
  The first character of an identifier must be an alphabetic character, either uppercase or lowercase, or an underscore ( **_** ). Because C++ identifiers are case sensitive, `fileName` is different from `FileName`.  
 
- Identifiers cannot be exactly the same spelling and case as keywords. Identifiers that contain keywords are legal. For example, `Pint` is a legal identifier, even though it contains `int`, which is a keyword.  
+ Identifiers cannot be exactly the same spelling and case as keywords. Identifiers that contain keywords are legal. For example, `Pint` is a legal identifier, even though it contains **int**, which is a keyword.  
 
  Use of two sequential underscore characters ( **__** ) at the beginning of an identifier, or a single leading underscore followed by a capital letter, is reserved for C++ implementations in all scopes. You should avoid using one leading underscore followed by a lowercase letter for names with file scope because of possible conflicts with current or future reserved identifiers.  
 

docs/cpp/if-else-statement-cpp.md

@@ -13,8 +13,8 @@ ms.author: "mblome"
 ms.workload: ["cplusplus"]
 ---
 # if-else Statement (C++)
-Controls conditional branching. Statements in the *if-block* are executed only if the *if-expression* evaluates to a non-zero value (or `true`). If the value of *expression* is nonzero, *statement1* and any other statements in the block are executed and the else-block, if present, is skipped. If the value of *expression* is zero, then the if-block is skipped and the else-block, if present, is executed. Expressions that evaluate to non-zero are
-- `true`
+Controls conditional branching. Statements in the *if-block* are executed only if the *if-expression* evaluates to a non-zero value (or TRUE). If the value of *expression* is nonzero, *statement1* and any other statements in the block are executed and the else-block, if present, is skipped. If the value of *expression* is zero, then the if-block is skipped and the else-block, if present, is executed. Expressions that evaluate to non-zero are
+- TRUE
 - a non-null pointer,
 - any non-zero arithmetic value, or 
 - a class type that defines an unambiguous conversion to an arithmetic, boolean or pointer type. (For information about conversions, see [Standard Conversions](../cpp/standard-conversions.md).)   
@@ -160,7 +160,7 @@ int main()
  The **else** clause of an `if...else` statement is associated with the closest previous **if** statement in the same scope that does not have a corresponding **else** statement.   
 
 ## constexpr if statements
-**Visual Studio 2017 version 15.3 and later** (available with [/std:c++17](../build/reference/std-specify-language-standard-version.md)): In function templates, you can use a **constexpr if** statement to make compile-time branching decisions without having to resort to multiple function overloads. For example, you can write a single function that handles parameter unpacking (no zero-parameter overload is needed): 
+**Visual Studio 2017 version 15.3 and later** (available with [/std:c++17](../build/reference/std-specify-language-standard-version.md)): In function templates, you can use a `constexpr if` statement to make compile-time branching decisions without having to resort to multiple function overloads. For example, you can write a single function that handles parameter unpacking (no zero-parameter overload is needed): 
 
 ```cpp
 template <class T, class... Rest>

docs/cpp/if-exists-statement.md

@@ -13,7 +13,7 @@ ms.author: "mblome"
 ms.workload: ["cplusplus"]
 ---
 # __if_exists Statement
-The `__if_exists` statement tests whether the specified identifier exists. If the identifier exists, the specified statement block is executed.  
+The **__if_exists** statement tests whether the specified identifier exists. If the identifier exists, the specified statement block is executed.  
 
 ## Syntax  
 
@@ -33,17 +33,17 @@ statements
 ## Remarks  
 
 > [!CAUTION]
->  To achieve the most reliable results, use the `__if_exists` statement under the following constraints.  
+>  To achieve the most reliable results, use the **__if_exists** statement under the following constraints.  
   
--   Apply the `__if_exists` statement to only simple types, not templates.  
+-   Apply the **__if_exists** statement to only simple types, not templates.  
 
--   Apply the `__if_exists` statement to identifiers both inside or outside a class. Do not apply the `__if_exists` statement to local variables.  
+-   Apply the **__if_exists** statement to identifiers both inside or outside a class. Do not apply the **__if_exists** statement to local variables.  
 
--   Use the `__if_exists` statement only in the body of a function. Outside of the body of a function, the `__if_exists` statement can test only fully defined types.  
+-   Use the **__if_exists** statement only in the body of a function. Outside of the body of a function, the **__if_exists** statement can test only fully defined types.  
 
 -   When you test for overloaded functions, you cannot test for a specific form of the overload.  
 
- The complement to the `__if_exists` statement is the [__if_not_exists](../cpp/if-not-exists-statement.md) statement.  
+ The complement to the **__if_exists** statement is the [__if_not_exists](../cpp/if-not-exists-statement.md) statement.  
 
 ## Example  
  Notice that this example uses templates, which is not advised.  

docs/cpp/if-not-exists-statement.md

@@ -13,7 +13,7 @@ ms.author: "mblome"
 ms.workload: ["cplusplus"]
 ---
 # __if_not_exists Statement
-The `__if_not_exists` statement tests whether the specified identifier exists. If the identifier does not exist, the specified statement block is executed.  
+The **__if_not_exists** statement tests whether the specified identifier exists. If the identifier does not exist, the specified statement block is executed.  
 
 ## Syntax  
 
@@ -33,20 +33,20 @@ statements
 ## Remarks  
 
 > [!CAUTION]
->  To achieve the most reliable results, use the `__if_not_exists` statement under the following constraints.  
+>  To achieve the most reliable results, use the **__if_not_exists** statement under the following constraints.  
   
--   Apply the `__if_not_exists` statement to only simple types, not templates.  
+-   Apply the **__if_not_exists** statement to only simple types, not templates.  
 
--   Apply the `__if_not_exists` statement to identifiers both inside or outside a class. Do not apply the `__if_not_exists` statement to local variables.  
+-   Apply the **__if_not_exists** statement to identifiers both inside or outside a class. Do not apply the **__if_not_exists** statement to local variables.  
 
--   Use the `__if_not_exists` statement only in the body of a function. Outside of the body of a function, the `__if_not_exists` statement can test only fully defined types.  
+-   Use the **__if_not_exists** statement only in the body of a function. Outside of the body of a function, the **__if_not_exists** statement can test only fully defined types.  
 
 -   When you test for overloaded functions, you cannot test for a specific form of the overload.  
 
- The complement to the `__if_not_exists` statement is the [__if_exists](../cpp/if-exists-statement.md) statement.  
+ The complement to the **__if_not_exists** statement is the [__if_exists](../cpp/if-exists-statement.md) statement.  
 
 ## Example  
- For an example about how to use `__if_not_exists`, see [__if_exists Statement](../cpp/if-exists-statement.md).  
+ For an example about how to use **__if_not_exists**, see [__if_exists Statement](../cpp/if-exists-statement.md).  
 
 ## See Also  
  [Selection Statements](../cpp/selection-statements-cpp.md)   

docs/cpp/increment-and-decrement-operator-overloading-cpp.md

@@ -18,10 +18,10 @@ The increment and decrement operators fall into a special category because there
 
 -   Predecrement and postdecrement  
 
- When you write overloaded operator functions, it can be useful to implement separate versions for the prefix and postfix versions of these operators. To distinguish between the two, the following rule is observed: The prefix form of the operator is declared exactly the same way as any other unary operator; the postfix form accepts an additional argument of type `int`.  
+ When you write overloaded operator functions, it can be useful to implement separate versions for the prefix and postfix versions of these operators. To distinguish between the two, the following rule is observed: The prefix form of the operator is declared exactly the same way as any other unary operator; the postfix form accepts an additional argument of type **int**.  
 
 > [!NOTE]
->  When specifying an overloaded operator for the postfix form of the increment or decrement operator, the additional argument must be of type `int`; specifying any other type generates an error.  
+>  When specifying an overloaded operator for the postfix form of the increment or decrement operator, the additional argument must be of type **int**; specifying any other type generates an error.  
   
  The following example shows how to define prefix and postfix increment and decrement operators for the `Point` class:  
 
@@ -93,7 +93,7 @@ friend Point& operator--( Point& )      // Prefix decrement
 friend Point& operator--( Point&, int ) // Postfix decrement  
 ```  
 
- The argument of type `int` that denotes the postfix form of the increment or decrement operator is not commonly used to pass arguments. It usually contains the value 0. However, it can be used as follows:  
+ The argument of type **int** that denotes the postfix form of the increment or decrement operator is not commonly used to pass arguments. It usually contains the value 0. However, it can be used as follows:  
 
 ```cpp  
 // increment_and_decrement2.cpp  

docs/cpp/inheritance-keywords.md

@@ -41,7 +41,7 @@ int S::*p;
 
 -   Using the [pointers_to_members](../preprocessor/pointers-to-members.md) pragma  
 
--   Using the inheritance keywords `__single_inheritance`, `__multiple_inheritance`, and `__virtual_inheritance`. This technique controls the inheritance model on a per-class basis.  
+-   Using the inheritance keywords **__single_inheritance**, **__multiple_inheritance**, and **__virtual_inheritance**. This technique controls the inheritance model on a per-class basis.  
 
     > [!NOTE]
     >  If you always declare a pointer to a member of a class after defining the class, you don't need to use any of these options.