-
Notifications
You must be signed in to change notification settings - Fork 967
Remove the content of the contrast between inline functions and macros #4823
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
Changes from 2 commits
91298f2
93025d3
d89ccce
994d366
1783fc0
4b2340d
9d3f5d3
14ca930
f9fee1a
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -13,4 +13,4 @@ _themes.VS.Modern/ | |
|
||
# Documentation build | ||
/docs/vcppdocs | ||
debug.log | ||
debug.log |
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -202,62 +202,6 @@ Assuming coordinate manipulation is a relatively common operation in a client of | |
|
||
- Return | ||
|
||
## Inline functions vs. macros | ||
|
||
Inline functions are similar to macros, because the function code is expanded at the point of the call at compile time. However, inline functions are parsed by the compiler, and macros are expanded by the preprocessor. As a result, there are several important differences: | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think we should keep this paragraph. It seems to me that only "Inline functions are similar to macros" needs to be improved. They are very different to me. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think we should also include the fact that inline substitution is not mandatory, it occurs at the compiler's discretion, in the list. Currently the wording is confusing. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @codeworm96 Your idea is also my idea. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
I agree. The statement is not that rigorous, and this causal relationship is also kind of far-fetched. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
I think we can just delete this paragraph and keep the last one:
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Replace this paragraph with: Inline functions vs. macrosinline functions are parsed by the compiler, and macros are expanded by the preprocessor. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The original wasn't good, and I'm not sure this is an improvement. 'Parsed by the compiler', although technically true, only indirectly conveys useful information. The crux of the matter that we are trying to get at is that the compiler, at its discretion, actually compiles the function and drops the code of the body into your code without the overhead of a function call, and with the benefit of actually going through the compiler so that language syntax and semantics are properly observed. |
||
|
||
- Inline functions follow all the protocols of type safety enforced on normal functions. | ||
|
||
- Inline functions are specified using the same syntax as any other function except that they include the **`inline`** keyword in the function declaration. | ||
|
||
- Expressions passed as arguments to inline functions are evaluated once. In some cases, expressions passed as arguments to macros can be evaluated more than once. | ||
|
||
The following example shows a macro that converts lowercase letters to uppercase: | ||
|
||
```cpp | ||
// inline_functions_macro.c | ||
#include <stdio.h> | ||
#include <conio.h> | ||
|
||
#define toupper(a) ((a) >= 'a' && ((a) <= 'z') ? ((a)-('a'-'A')):(a)) | ||
|
||
int main() { | ||
char ch; | ||
printf_s("Enter a character: "); | ||
ch = toupper( getc(stdin) ); | ||
printf_s( "%c", ch ); | ||
} | ||
// Sample Input: xyz | ||
// Sample Output: Z | ||
``` | ||
|
||
The intent of the expression `toupper(getc(stdin))` is that a character should be read from the console device (`stdin`) and, if necessary, converted to uppercase. | ||
|
||
Because of the implementation of the macro, `getc` is executed once to determine whether the character is greater than or equal to "a," and once to determine whether it's less than or equal to "z." If it is in that range, `getc` is executed again to convert the character to uppercase. It means the program waits for two or three characters when, ideally, it should wait for only one. | ||
|
||
Inline functions remedy the problem previously described: | ||
|
||
```cpp | ||
// inline_functions_inline.cpp | ||
#include <stdio.h> | ||
#include <conio.h> | ||
|
||
inline char toupper( char a ) { | ||
return ((a >= 'a' && a <= 'z') ? a-('a'-'A') : a ); | ||
} | ||
|
||
int main() { | ||
printf_s("Enter a character: "); | ||
char ch = toupper( getc(stdin) ); | ||
printf_s( "%c", ch ); | ||
} | ||
``` | ||
|
||
```Output | ||
Sample Input: a | ||
Sample Output: A | ||
``` | ||
|
||
## See also | ||
|
||
[`noinline`](../cpp/noinline.md)\ | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What is this change about? Can you revert this one?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for your reminding.
Didn't notice a blank line at the end, deleted.