Skip to content

Commit 12125b2

Browse files
authored
Merge pull request #5730 from MicrosoftDocs/FromPublicMasterBranch
Confirm merge from FromPublicMasterBranch to main to sync with https://github.com/MicrosoftDocs/cpp-docs (branch main)
2 parents 433e789 + 20177e3 commit 12125b2

16 files changed

+43
-46
lines changed

docs/build-insights/tutorials/build-insights-function-view.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -66,7 +66,7 @@ In the window for the ETL file, choose the **Functions** tab. It shows the funct
6666
In the Function Name column, performPhysicsCalculations() is highlighted and marked with a fire icon.:::
6767
:::image-end:::
6868

69-
The **Time [sec, %]** column shows how long it took to compile each function in [wall clock responsibility time (WCTR)](https://devblogs.microsoft.com/cppblog/faster-cpp-builds-simplified-a-new-metric-for-time/#:~:text=Today%2C%20we%E2%80%99d%20like%20to%20teach%20you%20about%20a,your%20build%2C%20even%20in%20the%20presence%20of%20parallelism). This metric distributes the wall clock time among functions based on their use of parallel compiler threads. For example, if two different threads are compiling two different functions simultaneously within a one-second period, each functions WCTR is recorded as 0.5 seconds. This reflects each functions proportional share of the total compilation time, taking into account the resources each consumed during parallel execution. Thus, WCTR provides a better measure of the impact each function has on the overall build time in environments where multiple compilation activities occur simultaneously.
69+
The **Time [sec, %]** column shows how long it took to compile each function in [wall clock responsibility time (WCTR)](https://devblogs.microsoft.com/cppblog/faster-cpp-builds-simplified-a-new-metric-for-time/#:~:text=Today%2C%20we%E2%80%99d%20like%20to%20teach%20you%20about%20a,your%20build%2C%20even%20in%20the%20presence%20of%20parallelism). This metric distributes the wall clock time among functions based on their use of parallel compiler threads. For example, if two different threads are compiling two different functions simultaneously within a one-second period, each function's WCTR is recorded as 0.5 seconds. This reflects each function's proportional share of the total compilation time, taking into account the resources each consumed during parallel execution. Thus, WCTR provides a better measure of the impact each function has on the overall build time in environments where multiple compilation activities occur simultaneously.
7070

7171
The **Forceinline Size** column shows roughly how many instructions were generated for the function. Click the chevron before the function name to see the individual inlined functions that were expanded in that function how roughly how many instructions were generated for each.
7272

docs/build-insights/tutorials/build-insights-included-files-view.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -171,7 +171,7 @@ Or, you can right-click a file in the **Include Tree** view to jump to it in the
171171
- The **Included Files** and **Include Tree** views provide a filter box to find a header file that you're interested in. It does partial matches on the name you provide.
172172
- Sometimes the parse time reported for a header file is different depending on which file includes it. This can be due to the interplay of different `#define`s that affect which parts of the header are expanded, file caching, and other system factors.
173173
- If you forget what the **Included Files** or **Include Tree** view is trying to show you, hover over the tab to see a tooltip that describes the view. For example, if you hover over the **Include Tree** tab, the tooltip says: "View that shows include statistics for every file where the children nodes are the files included by the parent node."
174-
- You may see cases (like `Windows.h`) where the aggregated duration of all the times for a header file is longer than the duration of the entire build. Whats happening is that headers are being parsed on multiple threads at the same time. If two threads simultaneously spend one second parsing a header file, that's 2 seconds of build time even though only one second of wall clock time has gone by. For more information, see [wall clock responsibility time (WCTR)](https://devblogs.microsoft.com/cppblog/faster-cpp-builds-simplified-a-new-metric-for-time/#:~:text=Today%2C%20we%E2%80%99d%20like%20to%20teach%20you%20about%20a,your%20build%2C%20even%20in%20the%20presence%20of%20parallelism).
174+
- You may see cases (like `Windows.h`) where the aggregated duration of all the times for a header file is longer than the duration of the entire build. What's happening is that headers are being parsed on multiple threads at the same time. If two threads simultaneously spend one second parsing a header file, that's 2 seconds of build time even though only one second of wall clock time has gone by. For more information, see [wall clock responsibility time (WCTR)](https://devblogs.microsoft.com/cppblog/faster-cpp-builds-simplified-a-new-metric-for-time/#:~:text=Today%2C%20we%E2%80%99d%20like%20to%20teach%20you%20about%20a,your%20build%2C%20even%20in%20the%20presence%20of%20parallelism).
175175

176176
## Troubleshooting
177177

docs/c-runtime-library/find-memory-leaks-using-the-crt-library.md

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -2,7 +2,7 @@
22
title: Find memory leaks with the CRT library
33
description: Learn how the C/C++ debugger and C Run-time Library (CRT) can help find memory leaks. The techniques include memory-leak reports and comparing memory snapshots.
44
ms.date: 02/03/2023
5-
helpviewer_keywords:
5+
helpviewer_keywords:
66
- breakpoints, on memory allocation
77
- _CrtMemState
88
- _CrtMemCheckpoint
@@ -165,7 +165,7 @@ struct Pod {
165165
int x;
166166
};
167167

168-
void main() {
168+
int main() {
169169
Pod* pPod = DBG_NEW Pod;
170170
pPod = DBG_NEW Pod; // Oops, leaked the original pPod!
171171
delete pPod;

docs/code-quality/c26135.md

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -25,14 +25,14 @@ typedef struct _DATA
2525
void MyEnter(DATA* p)
2626
{
2727
// Warning C26135:
28-
// Missing side effect annotation _Acquires_lock_(&p->cs)
28+
// Missing side effect annotation _Acquires_lock_(p->cs)
2929
EnterCriticalSection(&p->cs);
3030
}
3131

3232
void MyLeave(DATA* p)
3333
{
3434
// warning C26135:
35-
// Missing side effect annotation _Releases_lock_(&p->cs)
35+
// Missing side effect annotation _Releases_lock_(p->cs)
3636
LeaveCriticalSection(&p->cs);
3737
}
3838
```

docs/code-quality/c6387.md

Lines changed: 3 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -1,10 +1,9 @@
11
---
2-
description: "Learn more about: Warning C6387"
32
title: Warning C6387
3+
description: "Learn more about: Warning C6387"
44
ms.date: 11/04/2016
55
f1_keywords: ["C6387", "INVALID_PARAM_VALUE_1", "__WARNING_INVALID_PARAM_VALUE_1"]
66
helpviewer_keywords: ["C6387"]
7-
ms.assetid: 3ea2fc4d-ffc3-4c3c-bfae-d42aa56235d8
87
---
98
# Warning C6387
109

@@ -27,7 +26,7 @@ _Post_ _Null_ char * g();
2726

2827
void f(_In_ char *pch);
2928

30-
void main()
29+
int main()
3130
{
3231
char *pCh = g();
3332
f(pCh); // Warning C6387
@@ -43,7 +42,7 @@ _Post_ _Notnull_ char * g();
4342
4443
void f(_In_ char *pch);
4544
46-
void main()
45+
int main()
4746
{
4847
char *pCh = g();
4948
f(pCh);

docs/code-quality/c6394.md

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -1,6 +1,6 @@
11
---
2-
description: "Learn more about: Warning C6394"
32
title: Warning C6394
3+
description: "Learn more about: Warning C6394"
44
ms.date: 11/29/2023
55
f1_keywords: ["C6394", "LEAP_YEAR_INVALID_DATE_KEYED_LOOKUP_MUTABLE", "__WARNING_LEAP_YEAR_INVALID_DATE_KEYED_LOOKUP_MUTABLE"]
66
helpviewer_keywords: ["C6394"]
@@ -52,7 +52,7 @@ void foo(int year)
5252

5353
## Heuristics
5454

55-
This rule is enforced by checking if a lookup table has an initial size of 365 elements, but can be expanded to 366. However, it doesn't check if the tables size is adjusted through proper leap year check or not, and so is a low confidence warning.
55+
This rule is enforced by checking if a lookup table has an initial size of 365 elements, but can be expanded to 366. However, it doesn't check if the table's size is adjusted through proper leap year check or not, and so is a low confidence warning.
5656

5757
## See also
5858

docs/cppcx/fundamental-types-c-cx.md

Lines changed: 2 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -1,12 +1,11 @@
11
---
2-
description: "Learn more about: Fundamental types (C++/CX)"
32
title: "Fundamental types (C++/CX)"
3+
description: "Learn more about: Fundamental types (C++/CX)"
44
ms.date: "01/22/2017"
5-
ms.assetid: c9f82907-25f2-440b-91d6-afb8dbd46ea6
65
---
76
# Fundamental types (C++/CX)
87

9-
In addition to the standard C++ built-in types, C++/CX supports the type system that's defined by the Windows Runtime architecture by providing typedefs for the Windows Runtime fundamental types that map to standard C++ types.. C++/CX implements Boolean, character, and numeric fundamental types. These typedefs are defined in the `default` namespace, which never needs to be specified explicitly. In addition, C++/CX provides wrappers and concrete implementations for certain Windows Runtime types and interfaces.
8+
In addition to the standard C++ built-in types, C++/CX supports the type system that's defined by the Windows Runtime architecture by providing typedefs for the Windows Runtime fundamental types that map to standard C++ types. C++/CX implements Boolean, character, and numeric fundamental types. These typedefs are defined in the `default` namespace, which never needs to be specified explicitly. In addition, C++/CX provides wrappers and concrete implementations for certain Windows Runtime types and interfaces.
109

1110
## Boolean and Character Types
1211

docs/ide/include-cleanup-config.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -56,7 +56,7 @@ The `.editorconfig` settings that you can use with Include Cleanup are:
5656
|--|--|--|--|
5757
| `cpp_include_cleanup_add_missing_error_tag_type`</br></br>Sets the error level of add transitive include messages. | `none`</br>`suggestion`</br>`warning`</br>`error` | `cpp_include_cleanup_add_missing_error_tag_type = suggestion` |
5858
| `cpp_include_cleanup_remove_unused_error_tag_type`</br></br>Sets the error level of remove unused include messages. | `none`</br>`suggestion`</br>`warning`</br>`error`</br>`dimmed` | `cpp_include_cleanup_remove_unused_error_tag_type = dimmed` |
59-
| `cpp_include_cleanup_excluded_files`</br></br>Excludes the specified files from Include Cleanup messages. You wont get a suggestion related to the header at all, whether to add it or that it's unused. | *filename* | `cpp_include_cleanup_excluded_files = vcruntime.h, vcruntime_string.h` |
59+
| `cpp_include_cleanup_excluded_files`</br></br>Excludes the specified files from Include Cleanup messages. You won't get a suggestion related to the header at all, whether to add it or that it's unused. | *filename* | `cpp_include_cleanup_excluded_files = vcruntime.h, vcruntime_string.h` |
6060
| `cpp_include_cleanup_required_files`</br></br>Specify that usage of *file1* requires *file2*. For example, specify that if you use `atlwin.h` that `altbase.h` must also be included. | *file1*:*file2* | `cpp_include_cleanup_required_files = atlwin.h:altbase.h, atlcom.h:altbase.h` |
6161
| `cpp_include_cleanup_replacement_files`</br></br>Replaces *file1* with *file2* during Include Cleanup processing. For example, you may prefer using `cstdio` over `stdio.h`. If you have a file with both `#include <cstdio>` and `#include <stdio.h>` and you consume content only from `stdio.h`, with this setting Include Cleanup will tell you to remove `stdio.h` because it replaced the usage of `cstdio` with `stdio.h` during processing. If you don't use the contents from either, Include Cleanup will tell you to remove both.| *file1*:*file2* | `cpp_include_cleanup_replacement_files = stdio.h:cstdio,stdint.h:cstdint` |
6262
| `cpp_include_cleanup_alternate_files`</br></br>Don't generate a message for indirect include *file2* if *file1* is included. For example, if you `#include <windows.h>` and are only using something from its indirectly included header `winerror.h`, Include Cleanup won't prompt to add `winerror.h`. Useful when you prefer to include a facade header file instead of the indirect includes it contains. | *file1*:*file2* | `cpp_include_cleanup_alternate_files = windows.h:winerror.h, windows.h:minwindef.h` |

docs/ide/lnt-make-member-function-const.md

Lines changed: 7 additions & 7 deletions
Original file line numberDiff line numberDiff line change
@@ -8,7 +8,7 @@ monikerRange: ">=msvc-170"
88
---
99
# `lnt-make-member-function-const`
1010

11-
When a member function doesnt modify the object's state, annotate it with the `const` keyword. This guidance comes from the [C++ Core Guideline Con.2](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#con2-by-default-make-member-functions-const).
11+
When a member function doesn't modify the object's state, annotate it with the `const` keyword. This guidance comes from the [C++ Core Guideline Con.2](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#con2-by-default-make-member-functions-const).
1212

1313
## Example
1414

@@ -19,16 +19,16 @@ class MyClass
1919
{
2020
public:
2121

22-
int getValue() { return value; } // Flagged: getValue doesn't modify the object's state.
23-
void setValue(int newValue) { value = newValue; } // OK: setValue modifies the object's state.
22+
int getValue() { return value; } // Flagged: 'getValue' doesn't modify the object's state.
23+
void setValue(int newValue) { value = newValue; } // OK: 'setValue' modifies the object's state.
2424

2525
private:
2626

2727
int value = 42;
2828
};
2929

3030
double getRadius()
31-
{ // Flagged: getRadius doesn't modify the object's state.
31+
{ // Flagged: 'getRadius' doesn't modify the object's state.
3232
return radius;
3333
}
3434
```
@@ -45,7 +45,7 @@ class MyClass
4545
public:
4646

4747
int getValue() const { return value; } // Added const
48-
void setValue(int newValue) { value = newValue; } // OK: setValue modifies the object's state.
48+
void setValue(int newValue) { value = newValue; } // OK: 'setValue' modifies the object's state.
4949

5050
private:
5151

@@ -54,7 +54,7 @@ private:
5454
};
5555

5656
double getRadius() const // added const
57-
{ // getRadius doesn't modify the object's state.
57+
{ // 'getRadius' doesn't modify the object's state.
5858
return radius;
5959
}
6060
```
@@ -75,4 +75,4 @@ The current implementation of this check allows you to add `const` to member fun
7575

7676
## See also
7777

78-
[IntelliSense code linter for C++ overview](cpp-linter-overview.md)
78+
[IntelliSense code linter for C++ overview](cpp-linter-overview.md)

0 commit comments

Comments
 (0)