You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
# Data Directives and Operators in Inline Assembly
8
+
# Data directives and operators in inline assembly
9
9
10
10
**Microsoft Specific**
11
11
12
-
Although an **`__asm`** block can reference C or C++ data types and objects, it cannot define data objects with MASM directives or operators. Specifically, you cannot use the definition directives **DB**, `DW`, **DD**, `DQ`, `DT`, and `DF`, or the operators `DUP` or **THIS**. MASM structures and records are also unavailable. The inline assembler doesn't accept the directives `STRUC`, `RECORD`, **WIDTH**, or **MASK**.
12
+
The inline assembler doesn't support all the data directives and operators available in MASM.
13
+
14
+
## Remarks
15
+
16
+
Although an **`__asm`** block can reference C or C++ data types and objects, it can't define data objects with MASM directives or operators. Specifically, you can't use the definition directives **`DB`**, **`DW`**, **`DD`**, **`DQ`**, **`DT`**, and **`DF`**, or the operators **`DUP`** or **`THIS`**. MASM structures and records are also unavailable. The inline assembler doesn't accept the directives **`STRUC`**, **`RECORD`**, **`WIDTH`**, or **`MASK`**.
13
17
14
18
**END Microsoft Specific**
15
19
16
20
## See also
17
21
18
-
[Using Assembly Language in __asm Blocks](../../assembler/inline/using-assembly-language-in-asm-blocks.md)<br/>
22
+
[Using Assembly Language in `__asm` blocks](../../assembler/inline/using-assembly-language-in-asm-blocks.md)
Copy file name to clipboardExpand all lines: docs/build/cmake-presets-vs.md
+1-1Lines changed: 1 addition & 1 deletion
Original file line number
Diff line number
Diff line change
@@ -378,7 +378,7 @@ Instead, set the path to `vcpkg.cmake` by using the `VCPKG_ROOT` environment var
378
378
379
379
`VCPKG_ROOT` should be set to the root of your vcpkg installation. For more information, see [vcpkg environment variables](https://github.com/microsoft/vcpkg/blob/master/docs/users/config-environment.md).
380
380
381
-
If you're already using a CMake toolchain file and want to enable vcpkg integration, see [Using multiple toolchain files](https://github.com/microsoft/vcpkg/blob/master/docs/users/integration.md#using-multiple-toolchain-files). Follow those instructions to use an external toolchain file with a project by using vcpkg.
381
+
If you're already using a CMake toolchain file and want to enable vcpkg integration, see [Using multiple toolchain files](https://github.com/microsoft/vcpkg/blob/master/docs/users/buildsystems/integration.md#using-multiple-toolchain-files). Follow those instructions to use an external toolchain file with a project by using vcpkg.
382
382
383
383
## Variable substitution in *`launch.vs.json`* and *`tasks.vs.json`*
Copy file name to clipboardExpand all lines: docs/error-messages/compiler-errors-1/compiler-error-c2108.md
+6-4Lines changed: 6 additions & 4 deletions
Original file line number
Diff line number
Diff line change
@@ -1,20 +1,22 @@
1
1
---
2
2
description: "Learn more about: Compiler Error C2108"
3
3
title: "Compiler Error C2108"
4
-
ms.date: "11/04/2016"
4
+
ms.date: 06/03/2022
5
5
f1_keywords: ["C2108"]
6
6
helpviewer_keywords: ["C2108"]
7
7
ms.assetid: c84f0b47-5e2c-47d2-8edb-427a40e17c36
8
8
---
9
9
# Compiler Error C2108
10
10
11
-
subscript is not of integral type
11
+
> subscript is not of integral type
12
12
13
-
The array subscript is a noninteger expression.
13
+
## Remarks
14
+
15
+
The array subscript is a non-integer expression.
14
16
15
17
## Example
16
18
17
-
C2108 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).
19
+
C2108 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).
Copy file name to clipboardExpand all lines: docs/error-messages/compiler-errors-2/compiler-error-c2676.md
+5-3Lines changed: 5 additions & 3 deletions
Original file line number
Diff line number
Diff line change
@@ -1,14 +1,16 @@
1
1
---
2
2
description: "Learn more about: Compiler Error C2676"
3
3
title: "Compiler Error C2676"
4
-
ms.date: "11/04/2016"
4
+
ms.date: 06/03/2022
5
5
f1_keywords: ["C2676"]
6
6
helpviewer_keywords: ["C2676"]
7
7
ms.assetid: 838a5e34-c92f-4f65-a597-e150bf8cf737
8
8
---
9
9
# Compiler Error C2676
10
10
11
-
binary 'operator' : 'type' does not define this operator or a conversion to a type acceptable to the predefined operator
11
+
> binary '*operator*' : 'type*' does not define this operator or a conversion to a type acceptable to the predefined operator
12
+
13
+
## Remarks
12
14
13
15
To use the operator, you must overload it for the specified type or define a conversion to a type for which the operator is defined.
14
16
@@ -46,7 +48,7 @@ int main() {
46
48
47
49
C2676 can also occur if you attempt to do pointer arithmetic on the **`this`** pointer of a reference type.
48
50
49
-
The **`this`** pointer is of type handle in a reference type. 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).
51
+
The **`this`** pointer is of type handle in a reference type. 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).
Copy file name to clipboardExpand all lines: docs/error-messages/tool-errors/linker-tools-error-lnk1104.md
+1-1Lines changed: 1 addition & 1 deletion
Original file line number
Diff line number
Diff line change
@@ -126,4 +126,4 @@ If the *filename* is named LNK*nnn*, it's a filename generated by the linker for
126
126
127
127
When none of the issues listed here apply, you can use the feedback tools in Visual Studio for help. In the IDE, go to the menu bar and choose **Help > Send Feedback > Report a Problem**. Or, submit a suggestion by using **Help > Send Feedback > Send a Suggestion**. You can also use the [Microsoft Docs Q&A](/answers/topics/c%2B%2B.html) site for questions, and the Visual Studio C++ [Developer Community](https://aka.ms/vsfeedback/browsecpp) website. Use these sites to search for answers to questions and ask for help. For more information, see [How to report a problem with the Visual C++ toolset or documentation](../../overview/how-to-report-a-problem-with-the-visual-cpp-toolset.md).
128
128
129
-
If you've discovered a new way to fix this issue that we should add to this article, let us know. You can send us feedback by using the button below for **this page**. Use it to create a new issue in our [C++ documentation GitHub repo](https://github.com/MicrosoftDocs/cpp-docs/issues). Thanks!
129
+
If you've discovered a new way to fix this issue that we should add to this article, let us know. You can send us feedback by using the button below for **This page**. Use it to create a new issue in our [C++ documentation GitHub repo](https://github.com/MicrosoftDocs/cpp-docs/issues). Thanks!
This note describes the use of the [CWnd::PostNcDestroy](../mfc/reference/cwnd-class.md#postncdestroy) method. Use this method if you want to do customized allocation of `CWnd`-derived objects. This note also explains why you should use [CWnd::DestroyWindow](../mfc/reference/cwnd-class.md#destroywindow) to destroy a C++ Windows object instead of the **`delete`** operator.
11
+
This note describes the use of the [`CWnd::PostNcDestroy`](../mfc/reference/cwnd-class.md#postncdestroy) method. Use this method if you want to do customized allocation of `CWnd`-derived objects. This note also explains why you should use [`CWnd::DestroyWindow`](../mfc/reference/cwnd-class.md#destroywindow) to destroy a C++ Windows object instead of the **`delete`** operator.
12
12
13
-
If you follow the guidelines in this topic, you will have few cleanup problems. These problems can result from issues such as forgetting to delete/free C++ memory, forgetting to free system resources like `HWND`s, or freeing objects too many times.
13
+
If you follow the guidelines in this article, you'll have few cleanup problems. These problems can result from issues such as forgetting to delete/free C++ memory, forgetting to free system resources like `HWND`s, or freeing objects too many times.
14
14
15
-
## The Problem
15
+
## The problem
16
16
17
17
Each windows object (object of a class derived from `CWnd`) represents both a C++ object and an `HWND`. C++ objects are allocated in the application's heap and `HWND`s are allocated in system resources by the window manager. Because there are several ways to destroy a window object, we must provide a set of rules that prevent system resource or memory leaks. These rules must also prevent objects and Windows handles from being destroyed more than one time.
18
18
19
-
## Destroying Windows
19
+
## Destroying windows
20
20
21
21
The following are the two permitted ways to destroy a Windows object:
22
22
23
23
- Calling `CWnd::DestroyWindow` or the Windows API `DestroyWindow`.
24
24
25
25
- Explicitly deleting with the **`delete`** operator.
26
26
27
-
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.
27
+
The first case is by far the most common. This case applies even if your code doesn't 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.
28
28
29
29
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.
30
30
31
-
## Auto Cleanup with CWnd::PostNcDestroy
31
+
## Auto cleanup with `CWnd::PostNcDestroy`
32
32
33
-
When the system destroys a Windows window, the last Windows message sent to the window is WM_NCDESTROY. The default `CWnd` handler for that message is [CWnd::OnNcDestroy](../mfc/reference/cwnd-class.md#onncdestroy). `OnNcDestroy` will detach the `HWND` from the C++ object and call the virtual function `PostNcDestroy`. Some classes override this function to delete the C++ object.
33
+
When the system destroys a Windows window, the last Windows message sent to the window is `WM_NCDESTROY`. The default `CWnd` handler for that message is [`CWnd::OnNcDestroy`](../mfc/reference/cwnd-class.md#onncdestroy). `OnNcDestroy` will detach the `HWND` from the C++ object and call the virtual function `PostNcDestroy`. Some classes override this function to delete the C++ object.
34
34
35
-
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.
35
+
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 behavior isn't appropriate for window objects designed for allocation on the heap without any other objects. In other words, it isn't appropriate for window objects that aren't embedded in other C++ objects.
36
36
37
-
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.
37
+
Classes designed for allocation 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`* isn't `NULL`, this call doesn't lead to infinite recursion because the handle will be detached and `NULL` during the cleanup phase.
38
38
39
39
> [!NOTE]
40
-
> 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.
40
+
> 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 article.
41
41
42
-
## Auto Cleanup Classes
42
+
## Auto cleanup classes
43
43
44
-
The following classes are not designed for auto-cleanup. They are typically embedded in other C++ objects or on the stack:
44
+
The following classes aren't designed for auto-cleanup. They're typically embedded in other C++ objects or on the stack:
45
45
46
46
- All standard Windows controls (`CStatic`, `CEdit`, `CListBox`, and so on).
47
47
@@ -57,7 +57,7 @@ The following classes are not designed for auto-cleanup. They are typically embe
57
57
58
58
- The default dialogs created by ClassWizard.
59
59
60
-
The following classes are designed for auto-cleanup. They are typically allocated by themselves on the heap:
60
+
The following classes are designed for auto-cleanup. They're typically allocated by themselves on the heap:
61
61
62
62
- Main frame windows (derived directly or indirectly from `CFrameWnd`).
63
63
@@ -67,24 +67,24 @@ If you want to break these rules, you must override the `PostNcDestroy` method i
67
67
68
68
The most common use of changing auto cleanup behavior is to create a modeless dialog that can be allocated on the heap.
69
69
70
-
## When to Call delete
70
+
## When to call `delete`
71
71
72
72
We recommend that you call `DestroyWindow` to destroy a Windows object, either the C++ method or the global `DestroyWindow` API.
73
73
74
-
Do not call the global `DestroyWindow` API to destroy a MDI Child window. You should use the virtual method `CWnd::DestroyWindow` instead.
74
+
Don't call the global `DestroyWindow` API to destroy an MDI Child window. You should use the virtual method `CWnd::DestroyWindow` instead.
75
75
76
-
For C++ Window objects that do not perform auto-cleanup, using the **`delete`** operator can cause a memory leak when you try to call `DestroyWindow` in the `CWnd::~CWnd` destructor if the VTBL does not point to the correctly derived class. This occurs because the system cannot find the appropriate destroy method to call. Using `DestroyWindow` instead of **`delete`** avoids these problems. Because this can be a subtle error, compiling in debug mode will generate the following warning if you are at risk.
76
+
For C++ Window objects that don't perform auto-cleanup, using the **`delete`** operator can cause a memory leak when you try to call `DestroyWindow` in the `CWnd::~CWnd` destructor if the `VTBL` doesn't point to the correctly derived class. The leak occurs because the system can't find the appropriate destroy method to call. Using `DestroyWindow` instead of **`delete`** avoids these problems. Because this error can be subtle, compiling in debug mode will generate the following warning if you are at risk.
77
77
78
-
```
78
+
```Output
79
79
Warning: calling DestroyWindow in CWnd::~CWnd
80
80
OnDestroy or PostNcDestroy in derived class will not be called
81
81
```
82
82
83
-
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`.
83
+
For 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're 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`.
84
84
85
-
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`.
85
+
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`.
86
86
87
87
## See also
88
88
89
-
[Technical Notes by Number](../mfc/technical-notes-by-number.md)<br/>
90
-
[Technical Notes by Category](../mfc/technical-notes-by-category.md)
89
+
[Technical notes by number](../mfc/technical-notes-by-number.md)\
90
+
[Technical notes by category](../mfc/technical-notes-by-category.md)
0 commit comments