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
Copy file name to clipboardExpand all lines: docs/cpp/cdecl.md
+4-4Lines changed: 4 additions & 4 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -15,7 +15,7 @@ ms.workload: ["cplusplus"]
15
15
# __cdecl
16
16
**Microsoft Specific**
17
17
18
-
`__cdecl` is the default calling convention for C and C++ programs. Because the stack is cleaned up by the caller, it can do **vararg** functions. The `__cdecl` calling convention creates larger executables than [__stdcall](../cpp/stdcall.md), because it requires each function call to include stack cleanup code. The following list shows the implementation of this calling convention.
18
+
**__cdecl** is the default calling convention for C and C++ programs. Because the stack is cleaned up by the caller, it can do `vararg` functions. The **__cdecl** calling convention creates larger executables than [__stdcall](../cpp/stdcall.md), because it requires each function call to include stack cleanup code. The following list shows the implementation of this calling convention.
19
19
20
20
|Element|Implementation|
21
21
|-------------|--------------------|
@@ -27,9 +27,9 @@ ms.workload: ["cplusplus"]
27
27
> [!NOTE]
28
28
> For related information, see [Decorated Names](../build/reference/decorated-names.md).
29
29
30
-
Place the `__cdecl` modifier before a variable or a function name. Because the C naming and calling conventions are the default, the only time you must use `__cdecl` in x86 code is when you have specified the **/Gv** (vectorcall), **/Gz** (stdcall), or **/Gr** (fastcall) compiler option. The [/Gd](../build/reference/gd-gr-gv-gz-calling-convention.md) compiler option forces the `__cdecl` calling convention.
30
+
Place the **__cdecl** modifier before a variable or a function name. Because the C naming and calling conventions are the default, the only time you must use **__cdecl** in x86 code is when you have specified the `/Gv` (vectorcall), `/Gz` (stdcall), or `/Gr` (fastcall) compiler option. The [/Gd](../build/reference/gd-gr-gv-gz-calling-convention.md) compiler option forces the **__cdecl** calling convention.
31
31
32
-
On ARM and x64 processors, `__cdecl` is accepted but typically ignored by the compiler. By convention on ARM and x64, arguments are passed in registers when possible, and subsequent arguments are passed on the stack. In x64 code, use `__cdecl` to override the **/Gv** compiler option and use the default x64 calling convention.
32
+
On ARM and x64 processors, **__cdecl** is accepted but typically ignored by the compiler. By convention on ARM and x64, arguments are passed in registers when possible, and subsequent arguments are passed on the stack. In x64 code, use **__cdecl** to override the **/Gv** compiler option and use the default x64 calling convention.
33
33
34
34
For non-static class functions, if the function is defined out-of-line, the calling convention modifier does not have to be specified on the out-of-line definition. That is, for class non-static member methods, the calling convention specified during declaration is assumed at the point of definition. Given this class definition:
35
35
@@ -61,6 +61,6 @@ int __cdecl system(const char *);
Copy file name to clipboardExpand all lines: docs/cpp/char-wchar-t-char16-t-char32-t.md
+1-2Lines changed: 1 addition & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -31,5 +31,4 @@ The **wchar_t** type is an implementation-defined wide character type. In the Mi
31
31
32
32
The **char16_t** and **char32_t** types represent 16-bit and 32-bit wide characters, respectively. Unicode encoded as UTF-16 can be stored in the **char16_t** type, and Unicode encoded as UTF-32 can be stored in the **char32_t** type. Strings of these types and **wchar_t** are all referred to as *wide* strings, though the term often refers specifically to strings of **wchar_t** type.
33
33
34
-
In the C++ standard library, the `basic_string` type is specialized for both narrow and wide strings. Use `std::string` when the characters are of type **char**, `std::u16string` when the characters are of type **char16_t**, `std::u32string` when the characters are of type **char32_t**, and `std::wstring` when the characters are of type **wchar_t**. Other types that represent text, including `std::stringstream` and `std::cout` have specializations for narrow and wide strings.
35
-
34
+
In the C++ standard library, the `basic_string` type is specialized for both narrow and wide strings. Use `std::string` when the characters are of type **char**, `std::u16string` when the characters are of type **char16_t**, `std::u32string` when the characters are of type **char32_t**, and `std::wstring` when the characters are of type **wchar_t**. Other types that represent text, including `std::stringstream` and `std::cout` have specializations for narrow and wide strings.
Copy file name to clipboardExpand all lines: docs/cpp/character-sets.md
+1-2Lines changed: 1 addition & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -45,12 +45,11 @@ The text of a C++ program is stored in source files that use a particular charac
45
45
```cpp
46
46
auto \u30AD = 42; // \u30AD is 'キ'
47
47
if (キ == 42) returntrue; // \u30AD and キ are the same to the compiler
48
-
49
48
```
50
49
51
50
The format of extended characters on the Windows clipboard is specific to application locale settings. Cutting and pasting these characters into your code from another application may introduce unexpected character encodings. This can result in parsing errors with no visible cause in your code. We recommend that you set your source file encoding to a Unicode codepage before pasting extended characters. We also recommend that you use an IME or the Character Map app to generate extended characters.
52
51
53
52
**END Microsoft Specific**
54
53
55
54
### Basic execution character set
56
-
The *basic execution character set* and the *basic execution wide-character set* consist of all the characters in the basic source character set, and the control characters that represent alert, backspace, carriage return, and the null character. The *execution character set* and *execution wide-character set* are supersets of the basic sets. They include the implementation-defined source characters outside the basic source character set. The execution character set has a locale-specific representation.
55
+
The *basic execution character set* and the *basic execution wide-character set* consist of all the characters in the basic source character set, and the control characters that represent alert, backspace, carriage return, and the null character. The *execution character set* and *execution wide-character set* are supersets of the basic sets. They include the implementation-defined source characters outside the basic source character set. The execution character set has a locale-specific representation.
Copy file name to clipboardExpand all lines: docs/cpp/cleaning-up-resources.md
+5-5Lines changed: 5 additions & 5 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -12,18 +12,18 @@ ms.author: "mblome"
12
12
ms.workload: ["cplusplus"]
13
13
---
14
14
# Cleaning up Resources
15
-
During termination-handler execution, you may not know which resources are actually allocated before the termination handler was called. It is possible that the `__try` statement block was interrupted before all resources were allocated, so that not all resources were opened.
15
+
During termination-handler execution, you may not know which resources are actually allocated before the termination handler was called. It is possible that the **__try** statement block was interrupted before all resources were allocated, so that not all resources were opened.
16
16
17
17
Therefore, to be safe, you should check to see which resources are actually open before proceeding with termination-handling cleanup. A recommended procedure is to:
18
18
19
19
1. Initialize handles to NULL.
20
20
21
-
2. In the `__try` statement block, allocate resources. Handles are set to positive values as the resource is allocated.
21
+
2. In the **__try** statement block, allocate resources. Handles are set to positive values as the resource is allocated.
22
22
23
-
3. In the `__finally` statement block, release each resource whose corresponding handle or flag variable is nonzero or not NULL.
23
+
3. In the **__finally** statement block, release each resource whose corresponding handle or flag variable is nonzero or not NULL.
24
24
25
25
## Example
26
-
For example, the following code uses a termination handler to close three files and a memory block that were allocated in the `__try` statement block. Before cleaning up a resource, the code first checks to see if the resource was allocated.
26
+
For example, the following code uses a termination handler to close three files and a memory block that were allocated in the **__try** statement block. Before cleaning up a resource, the code first checks to see if the resource was allocated.
27
27
28
28
```cpp
29
29
// exceptions_Cleaning_up_Resources.cpp
@@ -63,6 +63,6 @@ int main() {
63
63
}
64
64
```
65
65
66
-
## See Also
66
+
## See also
67
67
[Writing a Termination Handler](../cpp/writing-a-termination-handler.md)
Copy file name to clipboardExpand all lines: docs/cpp/clrcall.md
+11-12Lines changed: 11 additions & 12 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -16,25 +16,25 @@ ms.workload: ["cplusplus"]
16
16
17
17
**Microsoft Specific**
18
18
19
-
Specifies that a function can only be called from managed code. Use `__clrcall` for all virtual functions that will only be called from managed code. However this calling convention cannot be used for functions that will be called from native code.
19
+
Specifies that a function can only be called from managed code. Use **__clrcall** for all virtual functions that will only be called from managed code. However this calling convention cannot be used for functions that will be called from native code.
20
20
21
-
Use `__clrcall` to improve performance when calling from a managed function to a virtual managed function or from managed function to managed function through pointer.
21
+
Use **__clrcall** to improve performance when calling from a managed function to a virtual managed function or from managed function to managed function through pointer.
22
22
23
-
Entry points are separate, compiler-generated functions. If a function has both native and managed entry points, one of them will be the actual function with the function implementation. The other function will be a separate function (a thunk) that calls into the actual function and lets the common language runtime perform PInvoke. When marking a function as `__clrcall`, you indicate the function implementation must be MSIL and that the native entry point function will not be generated.
23
+
Entry points are separate, compiler-generated functions. If a function has both native and managed entry points, one of them will be the actual function with the function implementation. The other function will be a separate function (a thunk) that calls into the actual function and lets the common language runtime perform PInvoke. When marking a function as **__clrcall**, you indicate the function implementation must be MSIL and that the native entry point function will not be generated.
24
24
25
-
When taking the address of a native function if `__clrcall` is not specified, the compiler uses the native entry point. `__clrcall` indicates that the function is managed and there is no need to go through the transition from managed to native. In that case the compiler uses the managed entry point.
25
+
When taking the address of a native function if **__clrcall** is not specified, the compiler uses the native entry point. **__clrcall** indicates that the function is managed and there is no need to go through the transition from managed to native. In that case the compiler uses the managed entry point.
26
26
27
-
When **/clr** (not **/clr:pure** or **/clr:safe**) is used and `__clrcall` is not used, taking the address of a function always returns the address of the native entry point function. When `__clrcall` is used, the native entry point function is not created, so you get the address of the managed function, not an entry point thunk function. For more information, see [Double Thunking](../dotnet/double-thunking-cpp.md). The **/clr:pure** and **/clr:safe** compiler options are deprecated in Visual Studio 2015 and unsupported in Visual Studio 2017.
27
+
When `/clr` (not `/clr:pure` or `/clr:safe`) is used and **__clrcall** is not used, taking the address of a function always returns the address of the native entry point function. When **__clrcall** is used, the native entry point function is not created, so you get the address of the managed function, not an entry point thunk function. For more information, see [Double Thunking](../dotnet/double-thunking-cpp.md). The **/clr:pure** and **/clr:safe** compiler options are deprecated in Visual Studio 2015 and unsupported in Visual Studio 2017.
28
28
29
-
[/clr (Common Language Runtime Compilation)](../build/reference/clr-common-language-runtime-compilation.md) implies that all functions and function pointers are `__clrcall` and the compiler will not permit a function inside the compiland to be marked anything other than `__clrcall`. When **/clr:pure** is used, `__clrcall` can only be specified on function pointers and external declarations.
29
+
[/clr (Common Language Runtime Compilation)](../build/reference/clr-common-language-runtime-compilation.md) implies that all functions and function pointers are **__clrcall** and the compiler will not permit a function inside the compiland to be marked anything other than **__clrcall**. When **/clr:pure** is used, **__clrcall** can only be specified on function pointers and external declarations.
30
30
31
-
You can directly call `__clrcall` functions from existing C++ code that was compiled by using **/clr** as long as that function has an MSIL implementation. `__clrcall` functions cannot be called directly from functions that have inline asm and call CPU-specific intrinisics, for example, even if those functions are compiled with **/clr**.
31
+
You can directly call **__clrcall** functions from existing C++ code that was compiled by using **/clr** as long as that function has an MSIL implementation. **__clrcall** functions cannot be called directly from functions that have inline asm and call CPU-specific intrinisics, for example, even if those functions are compiled with `/clr`.
32
32
33
-
`__clrcall` function pointers are only meant to be used in the application domain in which they were created. Instead of passing `__clrcall` function pointers across application domains, use <xref:System.CrossAppDomainDelegate>. For more information, see [Application Domains and Visual C++](../dotnet/application-domains-and-visual-cpp.md).
33
+
**__clrcall** function pointers are only meant to be used in the application domain in which they were created. Instead of passing **__clrcall** function pointers across application domains, use <xref:System.CrossAppDomainDelegate>. For more information, see [Application Domains and Visual C++](../dotnet/application-domains-and-visual-cpp.md).
34
34
35
35
## Example
36
36
37
-
Note that when a function is declared with `__clrcall`, code will be generated when needed; for example, when function is called.
37
+
Note that when a function is declared with **__clrcall**, code will be generated when needed; for example, when function is called.
38
38
39
39
```cpp
40
40
// clrcall2.cpp
@@ -92,6 +92,5 @@ int main() {
92
92
```
93
93
94
94
## See also
95
-
96
-
-[Argument Passing and Naming Conventions](../cpp/argument-passing-and-naming-conventions.md)
97
-
-[Keywords](../cpp/keywords-cpp.md)
95
+
[Argument Passing and Naming Conventions](../cpp/argument-passing-and-naming-conventions.md)
0 commit comments