Skip to content

Repo sync for protected branch #4711

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 8 commits into from
Sep 15, 2023
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
9 changes: 4 additions & 5 deletions docs/c-runtime-library/crt-initialization.md
Original file line number Diff line number Diff line change
Expand Up @@ -4,7 +4,6 @@ description: "Describes how the CRT initializes global state in native code."
ms.topic: "conceptual"
ms.date: 08/02/2021
helpviewer_keywords: ["CRT initialization [C++]"]
ms.assetid: e7979813-1856-4848-9639-f29c86b74ad7
---
# CRT initialization

Expand All @@ -16,9 +15,9 @@ It's possible, though not recommended, to take advantage of Microsoft-specific l

## Initializing a global object

Consider the following code:
Consider the following C++ code (C won't allow this code because it doesn't allow a function call in a constant expression).

```C
```cpp
int func(void)
{
return 3;
Expand Down Expand Up @@ -69,7 +68,6 @@ Offset Type Applied To Index Name
The CRT defines two pointers:

- `__xc_a` in `.CRT$XCA`

- `__xc_z` in `.CRT$XCZ`

Neither group has any other symbols defined except `__xc_a` and `__xc_z`.
Expand All @@ -88,7 +86,7 @@ The section should resemble this example:
__xc_z
```

So, the CRT library uses both `__xc_a` and `__xc_z` to determine the start and end of the global initializers list because of the way in which they're laid out in memory after the image is loaded.
The CRT library uses both `__xc_a` and `__xc_z` to determine the start and end of the global initializers list because of the way in which they're laid out in memory after the image is loaded.

## Linker features for initialization

Expand All @@ -112,4 +110,5 @@ The names `.CRT$XCT` and `.CRT$XCV` aren't used by either the compiler or the CR

## See also

[`_initterm, _initterm_e`](./reference/initterm-initterm-e.md)\
[C runtime (CRT) and C++ Standard Library (STL) `.lib` files](./crt-library-features.md)
5 changes: 2 additions & 3 deletions docs/cpp/decltype-cpp.md
Original file line number Diff line number Diff line change
@@ -1,10 +1,9 @@
---
description: "Learn more about: decltype (C++)"
title: "decltype (C++)"
ms.date: 09/27/2022
ms.date: 09/14/2023
f1_keywords: ["decltype_cpp"]
helpviewer_keywords: ["operators [C++], decltype", "decltype operator", "operators [C++], type of an expression", "operators [C++], deduce expression type"]
ms.assetid: 6dcf8888-8196-4f13-af50-51e3797255d4
---
# `decltype` (C++)

Expand Down Expand Up @@ -40,7 +39,7 @@ The following code example demonstrates some uses of the **`decltype`** type spe
```cpp
int var;
const int&& fx();
struct A { double x; }
struct A { double x; };
const A* a = new A();
```

Expand Down
11 changes: 6 additions & 5 deletions docs/cpp/fastcall.md
Original file line number Diff line number Diff line change
@@ -1,10 +1,9 @@
---
description: "Learn more about: __fastcall"
title: "__fastcall"
ms.date: "12/17/2018"
ms.date: 09/14/2023
f1_keywords: ["__fastcall_cpp", "__fastcall", "_fastcall"]
helpviewer_keywords: ["__fastcall keyword [C++]"]
ms.assetid: bb5b9c8a-dfad-450c-9119-0ac2bc59544f
---
# __fastcall

Expand All @@ -14,10 +13,12 @@ The **`__fastcall`** calling convention specifies that arguments to functions ar

|Element|Implementation|
|-------------|--------------------|
|Argument-passing order|The first two DWORD or smaller arguments that are found in the argument list from left to right are passed in ECX and EDX registers; all other arguments are passed on the stack from right to left.|
|Argument-passing order|The first two `DWORD` or smaller arguments that are found in the argument list from left to right are passed in ECX and EDX registers; all other arguments are passed on the stack from right to left.|
|Stack-maintenance responsibility|Called function pops the arguments from the stack.|
|Name-decoration convention|At sign (\@) is prefixed to names; an at sign followed by the number of bytes (in decimal) in the parameter list is suffixed to names.|
|Case-translation convention|No case translation performed.|
|Classes, structs, and unions|Treated as "multibyte" types (regardless of size) and passed on the stack. |
|Enums and enum classes | Passed by register if their underlying type is passed by register. For example, if the underlying type is `int` or `unsigned int` of size 8, 16, or 32 bits. |

> [!NOTE]
> Future compiler versions may use different registers to store parameters.
Expand All @@ -26,7 +27,7 @@ Using the [/Gr](../build/reference/gd-gr-gv-gz-calling-convention.md) compiler o

The **`__fastcall`** keyword is accepted and ignored by the compilers that target ARM and x64 architectures; on an x64 chip, by convention, the first four arguments are passed in registers when possible, and additional arguments are passed on the stack. For more information, see [x64 Calling Convention](../build/x64-calling-convention.md). On an ARM chip, up to four integer arguments and eight floating-point arguments may be passed in registers, and additional arguments are passed on the stack.

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:
For nonstatic class functions, if the function is defined out-of-line, the calling convention modifier doesn't 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:

```cpp
struct CMyClass {
Expand All @@ -46,7 +47,7 @@ is equivalent to this:
void __fastcall CMyClass::mymethod() { return; }
```

For compatibility with previous versions, **_fastcall** is a synonym for **`__fastcall`** unless compiler option [/Za \(Disable language extensions)](../build/reference/za-ze-disable-language-extensions.md) is specified.
For compatibility with previous versions, **`_fastcall`** is a synonym for **`__fastcall`** unless compiler option [/Za \(Disable language extensions)](../build/reference/za-ze-disable-language-extensions.md) is specified.

## Example

Expand Down