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
@@ -51,52 +51,52 @@ Visual Studio defines a CMake project as a folder with a `CMakeLists.txt` file a
51
51
52
52
3. From the Visual Studio **Get started** screen, select **Create a new project**.
53
53
54
-
54
+
55
55
56
56
4. In the **Search for templates** textbox, type "cmake". Choose the **CMake Project** type and select **Next**. Give the project a name and location, and then select **Create**.
57
57
58
58
5. Enable Visual Studio's CMake Presets integration. Select **Tools**>**Options**>**CMake**>**General**. Select **Prefer using CMake Presets for configure, build, and test**, thenselect**OK**. Instead, you could have added a `CMakePresets.json` file to the root of the project. For more information, see [Enable CMake Presets integration](cmake-presets-vs.md#enable-cmakepresets-json-integration).
59
59
60
-
60
+
61
61
62
62
6. To activate the integration: from the main menu, select**File**>**Close Folder**. The **Get started** page appears. Under **Open recent**, selectthe folder you just closed to reopen the folder.
63
63
64
64
7. There are three dropdowns across the Visual Studio main menu bar. Use the dropdown on the left to selectyour active target system. This is the system where CMake will be invoked to configure and build the project. Visual Studio queries for WSL installations with `wsl -l -v`. In the following image, **WSL2: Ubuntu-20.04** is shown selected as the **Target System**.
65
65
66
-
66
+
67
67
68
68
> [!NOTE]
69
69
> If Visual Studio starts to configure your project automatically, read step 11 to manage CMake binary deployment, and thencontinue to the step below. To customize this behavior, see [Modify automatic configuration and cache notifications](cmake-presets-vs.md#modify-automatic-configuration-and-cache-notifications).
70
70
71
71
8. Use the dropdown in the middle to selectyour active Configure Preset. Configure Presets tell Visual Studio how to invoke CMake and generate the underlying build system. In step 7, the active Configure Preset is the **linux-default** Preset created by Visual Studio. To create a custom Configure Preset, select**Manage Configurations…** For more information about Configure Presets, see [Select a Configure Preset](cmake-presets-vs.md#select-a-configure-preset) and [Edit Presets](cmake-presets-vs.md#edit-presets).
9. Use the dropdown on the right to selectyour active Build Preset. Build Presets tell Visual Studio how to invoke build. In the illustration for step 7, the active Build Preset is the **Default** Build Preset created by Visual Studio. For more information about Build Presets, see [Select a Build Preset](cmake-presets-vs.md#select-a-build-preset).
76
76
77
77
10. Configure the project on WSL 2. If project generation doesn't start automatically, then manually invoke configure with **Project** > **Configure** *project-name*
11. If you don't have a supported version of CMake installed on your WSL 2 distro, then Visual Studio will prompt you beneath the main menu ribbon to deploy a recent version of CMake. Select **Yes** to deploy CMake binaries to your WSL 2 distro.
82
82
83
-
83
+
84
84
85
85
12. Confirm that the configure step has completed and that you can see the **CMake generation finished** message in the **Output** window under the **CMake** pane. Build files are written to a directory in the WSL 2 distro's file system.
86
86
87
-
87
+
88
88
89
89
13. Select the active debug target. The debug dropdown menu lists all the CMake targets available to the project.
90
90
91
-
91
+
92
92
93
93
14. Expand the project subfolder in the **Solution Explorer**. In the `CMakeProject.cpp` file, set a breakpoint in `main()`. You can also navigate to CMake targets view by selecting the View Picker button in the **Solution Explorer**, highlighted in following screenshot:
94
94
95
-
95
+
96
96
97
97
15. Select **Debug** > **Start**, or press **F5**. Your project will build, the executable will launch on your WSL 2 distro, and Visual Studio will stop execution at the breakpoint. You can see the output of your program (in this case, `"Hello CMake."`) in the Linux Console Window:
98
98
99
-
99
+
100
100
101
101
You've now built and debugged a C++ app with WSL 2 and Visual Studio 2022.
102
102
@@ -118,11 +118,15 @@ You can change the IntelliSense mode, or specify other IntelliSense options, in
118
118
119
119
## WSL 2 and MSBuild-based Linux projects
120
120
121
-
CMake is recommended forall C++ cross-platform development with Visual Studio because it allows you to build and debug the same project on Windows, WSL, and remote systems. If you're already using a MSBuild-based Linux project, then you can upgrade to the WSL 2 toolsetin Visual Studio via **Property pages**>**General**>**Platform Toolset**:
121
+
CMake is recommended for all C++ cross-platform development with Visual Studio because it allows you to build and debug the same project on Windows, WSL, and remote systems.
122
122
123
-
123
+
But you may have a MSBuild-based Linux project.
124
124
125
-
If you're targeting a WSL 2 distribution and you don't want to use the WSL 2 toolset, thenin**Property Pages**>**General**>**Platform Toolset**, selectthe**GCC forWindows Subsystem for Linux** or **Clang for Windows Subsystem for Linux** toolset. If either of these toolsets are selected, Visual Studio won't maintain a copy of your source filesin the WSL file system and will instead access source files over the mounted Windows drive (`/mnt/`…). System headers are still automatically copied to the Windows file system to provide a native IntelliSense experience. Customize the headers that are included or excluded from this copy in**Property Pages**>**General**.
125
+
If you have a MSBuild-based Linux project, then you can upgrade to the WSL 2 toolset in Visual Studio. Right-click the project in the solution explorer, then choose **Properties**>**General**>**Platform Toolset**:
126
+
127
+
128
+
129
+
If you're targeting a WSL 2 distribution and you don't want to use the WSL 2 toolset, thenin the **Platform Toolset** dropdown, selectthe**GCC forWindows Subsystem for Linux** or **Clang for Windows Subsystem for Linux** toolset. If either of these toolsets are selected, Visual Studio won't maintain a copy of your source filesin the WSL file system and will instead access source files over the mounted Windows drive (`/mnt/`…). System headers are still automatically copied to the Windows file system to provide a native IntelliSense experience. Customize the headers that are included or excluded from this copy in**Property Pages**>**General**.
126
130
127
131
In most cases, it's best to use the WSL 2 toolset with WSL 2 distributions because WSL 2 is slower when project files are stored in the Windows file system. To to learn more, see [Comparing WSL 1 and WSL 2](/windows/wsl/compare-versions).
Copy file name to clipboardExpand all lines: docs/c-runtime-library/ansi-c-compliance.md
+1-1Lines changed: 1 addition & 1 deletion
Original file line number
Diff line number
Diff line change
@@ -13,7 +13,7 @@ The naming convention for all Microsoft-specific identifiers in the run-time sys
13
13
14
14
The names of Microsoft-specific functions and global variables begin with a single underscore. These names can be overridden only locally, within the scope of your code. For example, when you include Microsoft run-time header files, you can still locally override the Microsoft-specific function named `_open` by declaring a local variable of the same name. However, you can't use this name for your own global function or global variable.
15
15
16
-
The names of Microsoft-specific macros and manifest constants begin with two underscores, or with a single leading underscore immediately followed by an uppercase letter. The scope of such identifiers is absolute. For example, you can't use the Microsoft-specific identifier **_UPPER** for this reason.
16
+
The names of Microsoft-specific macros and manifest constants begin with two underscores, or with a single leading underscore immediately followed by an uppercase letter. The scope of such identifiers is absolute. For example, you can't use the Microsoft-specific identifier `_UPPER` for this reason.
The **va_arg**, **va_end**, and **va_start** macros provide access to function arguments when the number of arguments is variable. These macros are defined in \<stdarg.h> for ANSI/ISO C compatibility and in \<varargs.h> for compatibility with UNIX System V.
11
+
The `va_arg`, `va_end`, and `va_start` macros provide access to function arguments when the number of arguments is variable. These macros are defined in \<stdarg.h> for ANSI/ISO C compatibility and in \<varargs.h> for compatibility with UNIX System V.
Copy file name to clipboardExpand all lines: docs/c-runtime-library/cgets-cgetws.md
+2-2Lines changed: 2 additions & 2 deletions
Original file line number
Diff line number
Diff line change
@@ -46,7 +46,7 @@ Storage location for data.
46
46
47
47
## Return value
48
48
49
-
`_cgets` and `_cgetws` return a pointer to the start of the string, at `buffer[2]`. If `buffer` is **NULL**, these functions invoke the invalid parameter handler, as described in [Parameter validation](./parameter-validation.md). If execution is allowed to continue, they return **NULL** and set `errno` to `EINVAL`.
49
+
`_cgets` and `_cgetws` return a pointer to the start of the string, at `buffer[2]`. If `buffer` is `NULL`, these functions invoke the invalid parameter handler, as described in [Parameter validation](./parameter-validation.md). If execution is allowed to continue, they return `NULL` and set `errno` to `EINVAL`.
50
50
51
51
## Remarks
52
52
@@ -60,7 +60,7 @@ By default, this function's global state is scoped to the application. To change
60
60
61
61
### Generic-text routine mappings
62
62
63
-
|Tchar.h routine|_UNICODE and _MBCS not defined|_MBCS defined|_UNICODE defined|
63
+
|Tchar.h routine|`_UNICODE` and `_MBCS` not defined|`_MBCS` defined|`_UNICODE` defined|
Each of these routines tests a specified single-byte character, wide character, or multibyte character for satisfaction of a condition. (By definition, the ASCII character set between 0 and 127 are a subset of all multibyte-character sets. For example, Japanese katakana includes both ASCII and non-ASCII characters.)
12
12
13
-
The test conditions are affected by the setting of the **LC_CTYPE** category setting of the locale. For more information, see [`setlocale`](./reference/setlocale-wsetlocale.md). The versions of these functions without the **_l** suffix use the current locale for this locale-dependent behavior; the versions with the **_l** suffix are identical except that they use the locale parameter passed in instead.
13
+
The test conditions are affected by the setting of the `LC_CTYPE` category setting of the locale. For more information, see [`setlocale`](./reference/setlocale-wsetlocale.md). The versions of these functions without the `_l` suffix use the current locale for this locale-dependent behavior; the versions with the `_l` suffix are identical except that they use the locale parameter passed in instead.
14
14
15
15
Generally these routines execute faster than tests you might write and should be favored over. For example, the following code executes slower than a call to `isalpha(c)`:
|[`_mbclen`, `mblen`, `_mblen_l`](./reference/mbclen-mblen-mblen-l.md)|Return length of valid multibyte character; result depends on **LC_CTYPE** category setting of current locale|
50
+
|[`_mbclen`, `mblen`, `_mblen_l`](./reference/mbclen-mblen-mblen-l.md)|Return length of valid multibyte character; result depends on `LC_CTYPE` category setting of current locale|
Copy file name to clipboardExpand all lines: docs/c-runtime-library/code-pages.md
+1-1Lines changed: 1 addition & 1 deletion
Original file line number
Diff line number
Diff line change
@@ -26,7 +26,7 @@ The Microsoft runtime library uses the following types of code pages:
26
26
27
27
- Multibyte code page. The behavior of most of the multibyte-character routines in the run-time library depends on the current multibyte code page setting. By default, these routines use the system-default ANSI code page. At run-time you can query and change the multibyte code page with [`_getmbcp`](./reference/getmbcp.md) and [`_setmbcp`](./reference/setmbcp.md), respectively.
28
28
29
-
- The "C" locale is defined by ANSI to correspond to the locale in which C programs have traditionally executed. The code page for the "C" locale ("C" code page) corresponds to the ASCII character set. For example, in the "C" locale, **islower** returns true for the values 0x61 - 0x7A only. In another locale, **islower** may return `true` for these and other values, as defined by that locale.
29
+
- The "C" locale is defined by ANSI to correspond to the locale in which C programs have traditionally executed. The code page for the "C" locale ("C" code page) corresponds to the ASCII character set. For example, in the "C" locale, `islower` returns true for the values 0x61 - 0x7A only. In another locale, `islower` may return `true` for these and other values, as defined by that locale.
When the **_CRTDBG_MAP_ALLOC** flag is defined in the debug version of an application, the base versions of the heap functions are directly mapped to their debug versions. The flag is used in Crtdbg.h to do the mapping. This flag is only available when the [`_DEBUG`](./debug.md) flag has been defined in the application.
11
+
When the `_CRTDBG_MAP_ALLOC` flag is defined in the debug version of an application, the base versions of the heap functions are directly mapped to their debug versions. The flag is used in Crtdbg.h to do the mapping. This flag is only available when the [`_DEBUG`](./debug.md) flag has been defined in the application.
12
12
13
13
For more information about using the debug version versus the base version of a heap function, see [Using the debug version versus the base version](/visualstudio/debugger/debug-versions-of-heap-allocation-functions).
The **_crtDbgFlag** flag consists of five bit-fields that control how memory allocations on the debug version of the heap are tracked, verified, reported, and dumped. The bit fields of the flag are set using the [`_CrtSetDbgFlag`](./reference/crtsetdbgflag.md) function. This flag and its bit fields are declared in Crtdbg.h. This flag is only available when the [`_DEBUG`](./debug.md) flag has been defined in the application.
11
+
The **`_crtDbgFlag`** flag consists of five bit-fields that control how memory allocations on the debug version of the heap are tracked, verified, reported, and dumped. The bit fields of the flag are set using the [`_CrtSetDbgFlag`](./reference/crtsetdbgflag.md) function. This flag and its bit fields are declared in Crtdbg.h. This flag is only available when the [`_DEBUG`](./debug.md) flag has been defined in the application.
12
12
13
13
For more information about using this flag along with other debug functions, see [Heap state reporting functions](/visualstudio/debugger/crt-debug-heap-details).
0 commit comments