Merge pull request #4327 from corob-msft/docs/corob/check-this

Bulk Fix references to `this` outside std

Author: PRMerger8

docs/atl/reference/cwindowimpl-class.md

@@ -276,7 +276,7 @@ virtual void OnFinalMessage(HWND hWnd);
 
 ### Remarks
 
-The default implementation of `OnFinalMessage` does nothing, but you can override this function to handle cleanup before destroying a window. If you want to automatically delete your object upon the window destruction, you can call **delete this;** in this function.
+The default implementation of `OnFinalMessage` does nothing, but you can override this function to handle cleanup before destroying a window. If you want to automatically delete your object upon the window destruction, you can call `delete this;` in this function.
 
 ## <a name="subclasswindow"></a> CWindowImpl::SubclassWindow
 

docs/cpp/function-overloading.md

@@ -368,7 +368,7 @@ Even though the second one requires both a standard conversion and the user-defi
 > [!NOTE]
 > User-defined conversions are considered conversion by construction or conversion by initialization (conversion function). Both methods are considered equal when considering the best match.
 
-## Argument matching and the this pointer
+## Argument matching and the `this` pointer
 
 Class member functions are treated differently, depending on whether they are declared as **`static`**. Because nonstatic functions have an implicit argument that supplies the **`this`** pointer, nonstatic functions are considered to have one more argument than static functions; otherwise, they are declared identically.
 

docs/cpp/this-pointer.md

@@ -1,13 +1,13 @@
 ---
-title: "this pointer"
+title: "The this pointer"
 description: "The this pointer is a compiler-generated pointer to the current object in nonstatic member functions."
 ms.date: "01/22/2020"
 f1_keywords: ["this_cpp"]
 helpviewer_keywords: ["nonstatic member functions [C++]", "pointers, to class instance", "this pointer"]
 ms.assetid: 92e3256a-4ad9-4d46-8be1-d77fad90791f
 no-loc: [this, class, struct, union, sizeof, const, volatile]
 ---
-# this pointer
+# The `this` pointer
 
 The **`this`** pointer is a pointer accessible only within the nonstatic member functions of a **`class`**, **`struct`**, or **`union`** type. It points to the object for which the member function is called. Static member functions don't have a **`this`** pointer.
 
@@ -131,7 +131,7 @@ my buffer
 your buffer
 ```
 
-## Type of the this pointer
+## Type of the `this` pointer
 
 The **`this`** pointer's type can be modified in the function declaration by the **`const`** and **`volatile`** keywords. To declare a function that has either of these attributes, add the keyword(s) after the function argument list.
 
@@ -161,15 +161,15 @@ int main()
 }
 ```
 
-The type of **`this`** in a member function is described by the following syntax. The *cv-qualifier-list* is determined from the member function's declarator. It can be **`const`** or **`volatile`** (or both). *class-type* is the name of the class:
+The type of **`this`** in a member function is described by the following syntax. The *`cv-qualifier-list`* is determined from the member function's declarator. It can be **`const`** or **`volatile`** (or both). *`class-type`* is the name of the class:
 
-[*cv-qualifier-list*] *class-type* **\* const this**
+[*`cv-qualifier-list`*] *`class-type`* **`* const this`**
 
-In other words, the **`this`** pointer is always a const pointer. It can't be reassigned.  The **`const`** or **`volatile`** qualifiers used in the member function declaration apply to the class instance the **`this`** pointer points at, in the scope of that function.
+In other words, the **`this`** pointer is always a **`const`** pointer. It can't be reassigned.  The **`const`** or **`volatile`** qualifiers used in the member function declaration apply to the class instance the **`this`** pointer points at, in the scope of that function.
 
 The following table explains more about how these modifiers work.
 
-### Semantics of this modifiers
+### Semantics of `this` modifiers
 
 |Modifier|Meaning|
 |--------------|-------------|

docs/error-messages/compiler-errors-1/compiler-error-c2107.md

@@ -14,7 +14,7 @@ A subscript is applied to an expression that does not evaluate to a pointer.
 
 ## Example
 
-C2107 can occur if you incorrectly use the **`this`** pointer of a value type to access the type's default indexer. For more information, see [Semantics of the this pointer](../../dotnet/how-to-define-and-consume-classes-and-structs-cpp-cli.md#BKMK_Semantics_of_the_this_pointer).
+C2107 can occur if you incorrectly use the **`this`** pointer of a value type to access the type's default indexer. For more information, see [Semantics of the `this` pointer](../../dotnet/how-to-define-and-consume-classes-and-structs-cpp-cli.md#BKMK_Semantics_of_the_this_pointer).
 
 The following sample generates C2107.
 

docs/extensions/how-to-declare-value-types-with-the-interior-ptr-keyword-cpp-cli.md

@@ -58,7 +58,7 @@ int main() {
 3
 ```
 
-## Example: this pointer
+## Example: `this` pointer
 
 ### Description
 

docs/mfc/reference/cfindreplacedialog-class.md

@@ -98,7 +98,7 @@ CFindReplaceDialog();
 
 Because the `CFindReplaceDialog` object is a modeless dialog box, you must construct it on the heap by using the **`new`** operator.
 
-During destruction, the framework tries to perform a **delete this** on the pointer to the dialog box. If you created the dialog box on the stack, the **`this`** pointer does not exist and undefined behavior may result.
+During destruction, the framework tries to perform a `delete this;` on the pointer to the dialog box. If you created the dialog box on the stack, the **`this`** pointer does not exist and undefined behavior may result.
 
 For more information on the construction of `CFindReplaceDialog` objects, see the [CFindReplaceDialog](../../mfc/reference/cfindreplacedialog-class.md) overview. Use the [CFindReplaceDialog::Create](#create) member function to display the dialog box.
 

docs/mfc/tn017-destroying-window-objects.md

@@ -24,7 +24,7 @@ The following are the two permitted ways to destroy a Windows object:
 
 - Explicitly deleting with the **`delete`** operator.
 
-The first case is by far the most common. This case applies even if your code does not call `DestroyWindow` directly. When the user directly closes a frame window, this action generates the WM_CLOSE message, and the default response to this message is to call `DestroyWindow.` When a parent window is destroyed, Windows calls `DestroyWindow` for all its children.
+The first case is by far the most common. This case applies even if your code does not call `DestroyWindow` directly. When the user directly closes a frame window, this action generates the WM_CLOSE message, and the default response to this message is to call `DestroyWindow`. When a parent window is destroyed, Windows calls `DestroyWindow` for all its children.
 
 The second case, the use of the **`delete`** operator on Windows objects, should be rare. The following are some cases where using **`delete`** is the correct choice.
 
@@ -34,7 +34,7 @@ When the system destroys a Windows window, the last Windows message sent to the
 
 The default implementation of `CWnd::PostNcDestroy` does nothing, which is appropriate for window objects that are allocated on the stack frame or embedded in other objects. This is not appropriate for window objects that are designed to be allocated on the heap without any other objects. In other words, it is not appropriate for window objects that are not embedded in other C++ objects.
 
-Those classes that are designed to be allocated alone on the heap override the `PostNcDestroy` method to perform a **delete this**. This statement will free any memory associated with the C++ object. Even though the default `CWnd` destructor calls `DestroyWindow` if *m_hWnd* is non-NULL, this does not lead to infinite recursion because the handle will be detached and NULL during the cleanup phase.
+Those classes that are designed to be allocated alone on the heap override the `PostNcDestroy` method to perform a `delete this;`. This statement will free any memory associated with the C++ object. Even though the default `CWnd` destructor calls `DestroyWindow` if *m_hWnd* is non-NULL, this does not lead to infinite recursion because the handle will be detached and NULL during the cleanup phase.
 
 > [!NOTE]
 > The system usually calls `CWnd::PostNcDestroy` after it processes the Windows WM_NCDESTROY message and the `HWND` and the C++ window object are no longer connected. The system will also call `CWnd::PostNcDestroy` in the implementation of most [CWnd::Create](../mfc/reference/cwnd-class.md#create) calls if failure occurs. The auto cleanup rules are described later in this topic.
@@ -63,7 +63,7 @@ The following classes are designed for auto-cleanup. They are typically allocate
 
 - View windows (derived directly or indirectly from `CView`).
 
-If you want to break these rules, you must override the `PostNcDestroy` method in your derived class. To add auto-cleanup to your class, call your base class and then do a **delete this**. To remove auto-cleanup from your class, call `CWnd::PostNcDestroy` directly instead of the `PostNcDestroy` method of your direct base class.
+If you want to break these rules, you must override the `PostNcDestroy` method in your derived class. To add auto-cleanup to your class, call your base class and then do a `delete this;`. To remove auto-cleanup from your class, call `CWnd::PostNcDestroy` directly instead of the `PostNcDestroy` method of your direct base class.
 
 The most common use of changing auto cleanup behavior is to create a modeless dialog that can be allocated on the heap.
 
@@ -80,9 +80,9 @@ Warning: calling DestroyWindow in CWnd::~CWnd
     OnDestroy or PostNcDestroy in derived class will not be called
 ```
 
-In the case of C++ Windows objects that do perform auto-cleanup, you must call `DestroyWindow`. If you use the **`delete`** operator directly, the MFC diagnostic memory allocator will notify you that you are freeing memory two times. The two occurrences are your first explicit call and the indirect call to **delete this** in the auto-cleanup implementation of `PostNcDestroy`.
+In the case of C++ Windows objects that do perform auto-cleanup, you must call `DestroyWindow`. If you use the **`delete`** operator directly, the MFC diagnostic memory allocator will notify you that you are freeing memory two times. The two occurrences are your first explicit call and the indirect call to `delete this;` in the auto-cleanup implementation of `PostNcDestroy`.
 
-After calling `DestroyWindow` on a non-auto-cleanup object, the C++ object will still be around, but *m_hWnd* will be NULL. After calling `DestroyWindow` on an auto-cleanup object, the C++ object will be gone, freed by the C++ delete operator in the auto-cleanup implementation of `PostNcDestroy`.
+After you call `DestroyWindow` on a non-auto-cleanup object, the C++ object will still be around, but *m_hWnd* will be NULL. After you call `DestroyWindow` on an auto-cleanup object, the C++ object will be gone, freed by the C++ delete operator in the auto-cleanup implementation of `PostNcDestroy`.
 
 ## See also
 

docs/mfc/tn031-control-bars.md

@@ -49,7 +49,7 @@ The `CControlBar` class gives standard implementation for:
 
 - Supporting the implementation of derived classes.
 
-C++ control bar objects will usually be embedded as members of a `CFrameWnd` derived class, and will be cleaned up when the parent `HWND` and object are destroyed. If you need to allocate a control bar object on the heap, you can simply set the *m_bAutoDestruct* member to **TRUE** to make the control bar "**delete this**" when the `HWND` is destroyed.
+C++ control bar objects will usually be embedded as members of a `CFrameWnd` derived class, and will be cleaned up when the parent `HWND` and object are destroyed. If you need to allocate a control bar object on the heap, you can simply set the *m_bAutoDestruct* member to **TRUE** to make the control bar invoke `delete this;` when the `HWND` is destroyed.
 
 > [!NOTE]
 > If you create your own `CControlBar`-derived class, rather than using one of MFC's derived classes, such as `CStatusBar`, `CToolBar`, or `CDialogBar`, you will need to set the *m_dwStyle* data member. This can be done in the override of `Create`:

docs/overview/cpp-conformance-improvements-2017.md

@@ -387,7 +387,7 @@ There's now an implicit conversion for scoped enumerations that's non-narrowing.
 
 ### Capturing `*this` by value
 
-The **`*this`** object in a lambda expression may now be captured by value. This change enables scenarios in which the lambda is invoked in parallel and asynchronous operations, especially on newer machine architectures. For more information, see [P0018R3 - Lambda Capture of \*this by Value as \[=,\*this\]](https://wg21.link/p0018r3).
+The **`*this`** object in a lambda expression may now be captured by value. This change enables scenarios in which the lambda is invoked in parallel and asynchronous operations, especially on newer machine architectures. For more information, see [`P0018R3 - Lambda Capture of *this by Value as [=,*this]`](https://wg21.link/p0018r3).
 
 ### Removing `operator++` for `bool`
 

docs/parallel/amp/reference/index-class.md

@@ -129,7 +129,7 @@ index operator--(
 
 ### Return values
 
-For the prefix operator, the index object (*this). For the suffix operator, a new index object.
+For the prefix operator, the index object (`*this`). For the suffix operator, a new index object.
 
 ## <a name="operator_mod_eq"></a> operator%=
 
@@ -229,7 +229,7 @@ index<_Rank> operator++(
 
 ### Return Value
 
-For the prefix operator, the index object (*this). For the suffix operator, a new index object.
+For the prefix operator, the index object (`*this`). For the suffix operator, a new index object.
 
 ## <a name="operator_add_eq"></a> operator+=