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
You can control the NMAKE session by using preprocessing directives and expressions. Preprocessing instructions can be placed in the makefile or in *`Tools.ini`*. Using directives, you can conditionally process your makefile, display error messages, include other makefiles, undefine a macro, and turn certain options on or off.
11
11
@@ -129,6 +129,14 @@ Expressions can use the following operators. The operators of equal precedence a
129
129
130
130
To use a command's exit code during preprocessing, specify the command, with any arguments, within brackets (**`[ ]`**). Any macros are expanded before the command is executed. NMAKE replaces the command specification with the command's exit code, which can be used in an expression to control preprocessing.
The **`/Z7`**, **`/Zi`**, and **`/ZI`** compiler options specify the type of debugging information created for your program, and whether this information is kept in object files or in a program database (PDB) file.
11
11
@@ -23,15 +23,15 @@ When you specify a debug option, the compiler produces symbol names for function
23
23
24
24
By default, if no debug information format option is specified, the compiler produces no debugging information, so compilation is faster.
25
25
26
-
### /Z7
26
+
### `/Z7`
27
27
28
28
The **`/Z7`** option produces object files that also contain full symbolic debugging information for use with the debugger. These object files and any libraries built from them can be substantially larger than files that have no debugging information. The symbolic debugging information includes the names and types of variables, functions, and line numbers. No PDB file is produced by the compiler. However, a PDB file can still be generated from these object files or libraries if the linker is passed the **`/DEBUG`** option.
29
29
30
30
For distributors of debug versions of third-party libraries, there's an advantage to not having a PDB file. However, the object files for any precompiled headers are necessary during the library link phase, and for debugging. If there's only type information (and no code) in the *`.pch`* object file, you must also use the [`/Yl` (Inject PCH Reference for Debug Library)](yl-inject-pch-reference-for-debug-library.md) option, which is enabled by default, when you build the library.
31
31
32
32
The deprecated [`/Gm` (Enable Minimal Rebuild)](gm-enable-minimal-rebuild.md) option is unavailable when **`/Z7`** is specified.
33
33
34
-
### /Zi
34
+
### `/Zi`
35
35
36
36
The **`/Zi`** option produces a separate PDB file that contains all the symbolic debugging information for use with the debugger. The debugging information isn't included in the object files or executable, which makes them much smaller.
37
37
@@ -43,7 +43,7 @@ The compiler names the PDB file *`<project>.pdb`*, where *`<project>`* is the na
43
43
44
44
If you create a library from objects that were compiled using **`/Zi`**, the associated PDB file must be available when the library is linked to a program. That means, if you distribute the library, you must also distribute the PDB file. To create a library that contains debugging information without using PDB files, you must select the **`/Z7`** option. If you use the precompiled headers options, debugging information for both the precompiled header and the rest of the source code is placed in the PDB file.
45
45
46
-
### /ZI
46
+
### `/ZI`
47
47
48
48
The **`/ZI`** option is similar to **`/Zi`**, but it produces a PDB file in a format that supports the [Edit and Continue](/visualstudio/debugger/edit-and-continue-visual-cpp) feature. To use Edit and Continue debugging features, you must use this option. The Edit and Continue feature is useful for developer productivity, but can cause issues in code size, performance, and compiler conformance. Because most optimizations are incompatible with Edit and Continue, using **`/ZI`** disables any `#pragma optimize` statements in your code. The **`/ZI`** option is also incompatible with use of the [`__LINE__` predefined macro](../../preprocessor/predefined-macros.md); code compiled with **`/ZI`** can't use `__LINE__` as a non-type template argument, although `__LINE__` can be used in macro expansions.
# Walkthrough: Create and use your own Dynamic Link Library (C++)
@@ -30,6 +30,8 @@ This walkthrough creates two Visual Studio solutions; one that builds the DLL, a
30
30
31
31
This walkthrough doesn't cover some common situations. The code doesn't show the use of C++ DLLs by other programming languages. It doesn't show how to [create a resource-only DLL](creating-a-resource-only-dll.md), or how to use [explicit linking](linking-an-executable-to-a-dll.md#linking-explicitly) to load DLLs at run-time rather than at load-time. Rest assured, you can use MSVC and Visual Studio to do all these things.
32
32
33
+
Even though the code of the DLL is written in C++, we've used C-style interfaces for the exported functions. There are two main reasons for this: First, many other languages support imports of C-style functions. The client app doesn't have to be written in C++. Second, it avoids some common pitfalls related to exported classes and member functions. It's easy to make hard-to-diagnose errors when exporting classes, since everything referred to within a class declaration has to have an instantiation that's also exported. This restriction applies to DLLs, but not static libraries. If your classes are plain-old-data style, you shouldn't run into this issue.
34
+
33
35
For links to more information about DLLs, see [Create C/C++ DLLs in Visual Studio](dlls-in-visual-cpp.md). For more information about implicit linking and explicit linking, see [Determine which linking method to use](linking-an-executable-to-a-dll.md#determining-which-linking-method-to-use). For information about creating C++ DLLs for use with programming languages that use C-language linkage conventions, see [Exporting C++ functions for use in C-language executables](exporting-cpp-functions-for-use-in-c-language-executables.md). For information about how to create DLLs for use with .NET languages, see [Calling DLL Functions from Visual Basic Applications](calling-dll-functions-from-visual-basic-applications.md).
Microsoft C startup code uses the following rules when interpreting arguments given on the operating system command line:
13
13
14
-
- Arguments are delimited by white space, which is either a space or a tab.
14
+
- Arguments are delimited by whitespace characters, which are either spaces or tabs.
15
15
16
16
- The first argument (`argv[0]`) is treated specially. It represents the program name. Because it must be a valid pathname, parts surrounded by double quote marks (**`"`**) are allowed. The double quote marks aren't included in the `argv[0]` output. The parts surrounded by double quote marks prevent interpretation of a space or tab character as the end of the argument. The later rules in this list don't apply.
17
17
18
-
- A string surrounded by double quote marks is interpreted as a single argument, whether or not it contains white space. A quoted string can be embedded in an argument. The caret (**`^`**) isn't recognized as an escape character or delimiter. Within a quoted string, a pair of double quote marks is interpreted as a single escaped double quote mark. If the command line ends before a closing double quote mark is found, then all the characters read so far are output as the last argument.
18
+
- A string surrounded by double quote marks is interpreted as a single argument, whether it contains whitespace characters or not. A quoted string can be embedded in an argument. The caret (**`^`**) isn't recognized as an escape character or delimiter. Within a quoted string, a pair of double quote marks is interpreted as a single escaped double quote mark. If the command line ends before a closing double quote mark is found, then all the characters read so far are output as the last argument.
19
19
20
20
- A double quote mark preceded by a backslash (**`\"`**) is interpreted as a literal double quote mark (**`"`**).
21
21
@@ -27,14 +27,14 @@ Microsoft C startup code uses the following rules when interpreting arguments gi
27
27
28
28
This list illustrates the rules above by showing the interpreted result passed to `argv` for several examples of command-line arguments. The output listed in the second, third, and fourth columns is from the ARGS.C program that follows the list.
# Left Shift and Right Shift Operators (`<<` and `>>`)
9
+
# Left shift and right shift operators (`<<` and `>>`)
10
10
11
-
The bitwise shift operators are the right-shift operator (**`>>`**), which moves the bits of *shift-expression* to the right, and the left-shift operator (**`<<`**), which moves the bits of *shift-expression* to the left. <sup>1</sup>
11
+
The bitwise shift operators are the right-shift operator (**`>>`**), which moves the bits of an integer or enumeration type expression to the right, and the left-shift operator (**`<<`**), which moves the bits to the left. <sup>1</sup>
@@ -22,7 +24,7 @@ The bitwise shift operators are the right-shift operator (**`>>`**), which moves
22
24
23
25
## Left Shifts
24
26
25
-
The left-shift operator causes the bits in *shift-expression* to be shifted to the left by the number of positions specified by *additive-expression*. The bit positions that have been vacated by the shift operation are zero-filled. A left shift is a logical shift (the bits that are shifted off the end are discarded, including the sign bit). For more information about the kinds of bitwise shifts, see [Bitwise shifts](https://en.wikipedia.org/wiki/Bitwise_shift).
27
+
The left-shift operator causes the bits in *`shift-expression`* to be shifted to the left by the number of positions specified by *`additive-expression`*. The bit positions that have been vacated by the shift operation are zero-filled. A left shift is a logical shift (the bits that are shifted off the end are discarded, including the sign bit). For more information about the kinds of bitwise shifts, see [Bitwise shifts](https://en.wikipedia.org/wiki/Bitwise_shift).
26
28
27
29
The following example shows left-shift operations using unsigned numbers. The example shows what is happening to the bits by representing the value as a bitset. For more information, see [bitset Class](../standard-library/bitset-class.md).
28
30
@@ -72,7 +74,7 @@ int main() {
72
74
73
75
## Right Shifts
74
76
75
-
The right-shift operator causes the bit pattern in *shift-expression* to be shifted to the right by the number of positions specified by *additive-expression*. For unsigned numbers, the bit positions that have been vacated by the shift operation are zero-filled. For signed numbers, the sign bit is used to fill the vacated bit positions. In other words, if the number is positive, 0 is used, and if the number is negative, 1 is used.
77
+
The right-shift operator causes the bit pattern in *`shift-expression`* to be shifted to the right by the number of positions specified by *`additive-expression`*. For unsigned numbers, the bit positions that have been vacated by the shift operation are zero-filled. For signed numbers, the sign bit is used to fill the vacated bit positions. In other words, if the number is positive, 0 is used, and if the number is negative, 1 is used.
76
78
77
79
> [!IMPORTANT]
78
80
> The result of a right-shift of a signed negative number is implementation-dependent. Although the Microsoft C++ compiler uses the sign bit to fill vacated bit positions, there is no guarantee that other implementations also do so.
@@ -158,9 +160,9 @@ int main() {
158
160
}
159
161
```
160
162
161
-
## Shifts and Promotions
163
+
## Shifts and promotions
162
164
163
-
The expressions on both sides of a shift operator must be integral types. Integral promotions are performed according to the rules described in [Standard Conversions](standard-conversions.md). The type of the result is the same as the type of the promoted *shift-expression*.
165
+
The expressions on both sides of a shift operator must be integral types. Integral promotions are performed according to the rules described in [Standard Conversions](standard-conversions.md). The type of the result is the same as the type of the promoted *`shift-expression`*.
164
166
165
167
In the following example, a variable of type **`char`** is promoted to an **`int`**.
166
168
@@ -181,9 +183,9 @@ int main() {
181
183
}
182
184
```
183
185
184
-
## Additional Details
186
+
## Details
185
187
186
-
The result of a shift operation is undefined if *additive-expression* is negative or if *additive-expression* is greater than or equal to the number of bits in the (promoted) *shift-expression*. No shift operation is performed if *additive-expression* is 0.
188
+
The result of a shift operation is undefined if *`additive-expression`* is negative or if *`additive-expression`* is greater than or equal to the number of bits in the (promoted) *`shift-expression`*. No shift operation takes place if *`additive-expression`* is 0.
187
189
188
190
```cpp
189
191
#include<iostream>
@@ -216,5 +218,5 @@ The value of `E1 >> E2` is `E1` right-shifted `E2` bit positions. If `E1` has an
216
218
217
219
## See also
218
220
219
-
[Expressions with Binary Operators](../cpp/expressions-with-binary-operators.md)<br/>
220
-
[C++ Built-in Operators, Precedence and Associativity](../cpp/cpp-built-in-operators-precedence-and-associativity.md)
221
+
[Expressions with binary operators](../cpp/expressions-with-binary-operators.md)<br/>
222
+
[C++ built-in operators, precedence, and associativity](../cpp/cpp-built-in-operators-precedence-and-associativity.md)
0 commit comments