Keywords that I don't understand
-
Hi fellows I'm programming C++ approximately 1 1/2 year, and I programming for windows too. But some keywords I don't know exactly what they are and when I use them. That's my question: What the meaning of terms and when I use them: __stdcall __pascal __fastcall __thiscall inline It seems that's beginner question but I would like some answer to this question Thanks for help again
-
Hi fellows I'm programming C++ approximately 1 1/2 year, and I programming for windows too. But some keywords I don't know exactly what they are and when I use them. That's my question: What the meaning of terms and when I use them: __stdcall __pascal __fastcall __thiscall inline It seems that's beginner question but I would like some answer to this question Thanks for help again
All these are calling conventions. Actually
__thiscallis not a keyword last time I checked. The calling convention specifies the mechanics of calling a function at the machine code level: it dictates such things as whose responsibility it is to clean up the stack and how arguments are passed. If you want to know more details you’ll have to learn some machine code.Steve
-
Hi fellows I'm programming C++ approximately 1 1/2 year, and I programming for windows too. But some keywords I don't know exactly what they are and when I use them. That's my question: What the meaning of terms and when I use them: __stdcall __pascal __fastcall __thiscall inline It seems that's beginner question but I would like some answer to this question Thanks for help again
In addition to what's been said, know that in Windows, native DLL [edit] exported [/edit] functions have to be __stdcall. This affects stuff like stack order, which registers are used, etc. But the reality of it is in practice, make sure you don't use one type in a library and define it as a different one in the header. You'll get plenty of linker errors that way. Btw, inline is in a court all its own. Rather than calling a function, the compiler attempts to take the body of that function and insert it into the block it was called from, thus saving the overhead of calling the function. Of course, if you call an inline function a lot, you'll increase the size of your exe substantially.
Jeremy Falcon "It's a good thing to do and a tasty way to do it." - Wilford Brimley[^]
-
In addition to what's been said, know that in Windows, native DLL [edit] exported [/edit] functions have to be __stdcall. This affects stuff like stack order, which registers are used, etc. But the reality of it is in practice, make sure you don't use one type in a library and define it as a different one in the header. You'll get plenty of linker errors that way. Btw, inline is in a court all its own. Rather than calling a function, the compiler attempts to take the body of that function and insert it into the block it was called from, thus saving the overhead of calling the function. Of course, if you call an inline function a lot, you'll increase the size of your exe substantially.
Jeremy Falcon "It's a good thing to do and a tasty way to do it." - Wilford Brimley[^]
Jeremy Falcon wrote:
Of course, if you call an inline function a lot, you'll increase the size of your exe substantially.
This is not true for really small functions. For example if a function simply added two numbers or returned some value then the function call overhead will be bigger then the actual code and inlining will save time and space.
Steve
-
Jeremy Falcon wrote:
Of course, if you call an inline function a lot, you'll increase the size of your exe substantially.
This is not true for really small functions. For example if a function simply added two numbers or returned some value then the function call overhead will be bigger then the actual code and inlining will save time and space.
Steve
We both know the smaller the function the less the increase in executable, so my statement isn't incorrect. But the increase is still substantial relative to the routine. Nevertheless, what you just described is really better served as a macro, considering the restrictions on inline functions and compiler issues associated with them.
Jeremy Falcon "It's a good thing to do and a tasty way to do it." - Wilford Brimley[^]
-
We both know the smaller the function the less the increase in executable, so my statement isn't incorrect. But the increase is still substantial relative to the routine. Nevertheless, what you just described is really better served as a macro, considering the restrictions on inline functions and compiler issues associated with them.
Jeremy Falcon "It's a good thing to do and a tasty way to do it." - Wilford Brimley[^]
Jeremy Falcon wrote:
We both know the smaller the function the less the increase in executable, so my statement isn't incorrect. But the increase is still substantial relative to the routine.
Here's some code I used to measure:
// InlineSmaller.cpp : Defines the entry point for the console application.
//
#include "stdafx.h"
#include <iostream>
inline int Add(int l, int r)
{
return l+r;
}
void PrintResult(int r)
{
using namespace std;
cout << r << endl;
}
int main(int argc, char* argv[])
{
int res = Add(1, 2);
PrintResult(res);
return 0;
}I compiled twice: once with the
inlineon theAddfunction and once without. Here's the code with theinline:18: int main(int argc, char* argv[])
19: {
004010F0 6A 03 push 3
004010F2 E8 89 FF FF FF call PrintResult (00401080)
004010F7 83 C4 04 add esp,4
20: int res = Add(1, 2);
21: PrintResult(res);
22:
23: return 0;
004010FA 33 C0 xor eax,eax
24: }
004010FC C3 retAs you can see the
Addcall has been entirely optimised away to apush 3! Here's the code with theinlinecommented out:7: /*inline*/ int Add(int l, int r)
8: {
00401080 8B 44 24 08 mov eax,dword ptr [esp+8]
00401084 8B 4C 24 04 mov ecx,dword ptr [esp+4]
00401088 03 C1 add eax,ecx
9: return l+r;
10: }
0040108A C3 ret
18: int main(int argc, char* argv[])
19: {
00401100 6A 02 push 2
00401102 6A 01 push 1
00401104 E8 77 FF FF FF call Add (00401080)
20: int res = Add(1, 2);
21: PrintResult(res);
00401109 50 push eax
0040110A E8 81 FF FF FF call PrintResult (00401090)
0040110F 83 C4 0C add esp,0Ch
22:
23: return 0;
00401112 33 C0 xor eax,eax
24: }
00401114 C3 retWe have an
Addfunction andmainis bigger! My statement is correct: usinginlineon small functions can and often does make the code smaller (and faster)! We saved 19 bytes of code by adding theinline! -
Jeremy Falcon wrote:
We both know the smaller the function the less the increase in executable, so my statement isn't incorrect. But the increase is still substantial relative to the routine.
Here's some code I used to measure:
// InlineSmaller.cpp : Defines the entry point for the console application.
//
#include "stdafx.h"
#include <iostream>
inline int Add(int l, int r)
{
return l+r;
}
void PrintResult(int r)
{
using namespace std;
cout << r << endl;
}
int main(int argc, char* argv[])
{
int res = Add(1, 2);
PrintResult(res);
return 0;
}I compiled twice: once with the
inlineon theAddfunction and once without. Here's the code with theinline:18: int main(int argc, char* argv[])
19: {
004010F0 6A 03 push 3
004010F2 E8 89 FF FF FF call PrintResult (00401080)
004010F7 83 C4 04 add esp,4
20: int res = Add(1, 2);
21: PrintResult(res);
22:
23: return 0;
004010FA 33 C0 xor eax,eax
24: }
004010FC C3 retAs you can see the
Addcall has been entirely optimised away to apush 3! Here's the code with theinlinecommented out:7: /*inline*/ int Add(int l, int r)
8: {
00401080 8B 44 24 08 mov eax,dword ptr [esp+8]
00401084 8B 4C 24 04 mov ecx,dword ptr [esp+4]
00401088 03 C1 add eax,ecx
9: return l+r;
10: }
0040108A C3 ret
18: int main(int argc, char* argv[])
19: {
00401100 6A 02 push 2
00401102 6A 01 push 1
00401104 E8 77 FF FF FF call Add (00401080)
20: int res = Add(1, 2);
21: PrintResult(res);
00401109 50 push eax
0040110A E8 81 FF FF FF call PrintResult (00401090)
0040110F 83 C4 0C add esp,0Ch
22:
23: return 0;
00401112 33 C0 xor eax,eax
24: }
00401114 C3 retWe have an
Addfunction andmainis bigger! My statement is correct: usinginlineon small functions can and often does make the code smaller (and faster)! We saved 19 bytes of code by adding theinline!In your attempt to be pretentious you overlooked the fact I didn't deny your points on one-line routines. I suggest you actually read my posts this time around. Also, it's true macros are not type safe inherently, but the contents of it are as it's just code. And, if you reread what I said (and this time actually read) macros do avoid the compiler issues AND usage restrictions associated with inline routines. And no, use Google if you're really interested on what those are. Never use an inline function in place of a one-line macro, assuming you care about portable code - which you apparently do not.
Jeremy Falcon "It's a good thing to do and a tasty way to do it." - Wilford Brimley[^]
-
Jeremy Falcon wrote:
We both know the smaller the function the less the increase in executable, so my statement isn't incorrect. But the increase is still substantial relative to the routine.
Here's some code I used to measure:
// InlineSmaller.cpp : Defines the entry point for the console application.
//
#include "stdafx.h"
#include <iostream>
inline int Add(int l, int r)
{
return l+r;
}
void PrintResult(int r)
{
using namespace std;
cout << r << endl;
}
int main(int argc, char* argv[])
{
int res = Add(1, 2);
PrintResult(res);
return 0;
}I compiled twice: once with the
inlineon theAddfunction and once without. Here's the code with theinline:18: int main(int argc, char* argv[])
19: {
004010F0 6A 03 push 3
004010F2 E8 89 FF FF FF call PrintResult (00401080)
004010F7 83 C4 04 add esp,4
20: int res = Add(1, 2);
21: PrintResult(res);
22:
23: return 0;
004010FA 33 C0 xor eax,eax
24: }
004010FC C3 retAs you can see the
Addcall has been entirely optimised away to apush 3! Here's the code with theinlinecommented out:7: /*inline*/ int Add(int l, int r)
8: {
00401080 8B 44 24 08 mov eax,dword ptr [esp+8]
00401084 8B 4C 24 04 mov ecx,dword ptr [esp+4]
00401088 03 C1 add eax,ecx
9: return l+r;
10: }
0040108A C3 ret
18: int main(int argc, char* argv[])
19: {
00401100 6A 02 push 2
00401102 6A 01 push 1
00401104 E8 77 FF FF FF call Add (00401080)
20: int res = Add(1, 2);
21: PrintResult(res);
00401109 50 push eax
0040110A E8 81 FF FF FF call PrintResult (00401090)
0040110F 83 C4 0C add esp,0Ch
22:
23: return 0;
00401112 33 C0 xor eax,eax
24: }
00401114 C3 retWe have an
Addfunction andmainis bigger! My statement is correct: usinginlineon small functions can and often does make the code smaller (and faster)! We saved 19 bytes of code by adding theinline!Stephen Hewitt wrote:
Macros make debugging harder and are not type safe.
Also, if you need a debugger for a one-line routine, let's just say you're better off being a Wal-Mart cashier. Let's get real man, you know that realistically speaking a one line routine isn't that big of a deal to debug. Or dare I say, just copy and paste the contents of the macro into a block and run it if you must and then put the modified code back into the macro. The benefits outweigh having to use two extra keystrokes IMO.
Jeremy Falcon "It's a good thing to do and a tasty way to do it." - Wilford Brimley[^]
-
In your attempt to be pretentious you overlooked the fact I didn't deny your points on one-line routines. I suggest you actually read my posts this time around. Also, it's true macros are not type safe inherently, but the contents of it are as it's just code. And, if you reread what I said (and this time actually read) macros do avoid the compiler issues AND usage restrictions associated with inline routines. And no, use Google if you're really interested on what those are. Never use an inline function in place of a one-line macro, assuming you care about portable code - which you apparently do not.
Jeremy Falcon "It's a good thing to do and a tasty way to do it." - Wilford Brimley[^]
I was not (and am not) attempting to be pretentious. I said that your original statement about inline functions making functions bigger was “not true for really small functions.”:
Jeremy Falcon wrote:
Of course, if you call an inline function a lot, you'll increase the size of your exe substantially.
Stephen Hewitt wrote:
This is not true for really small functions. For example if a function simply added two numbers or returned some value then the function call overhead will be bigger then the actual code and inlining will save time and space.
To this you replied as follows:
Jeremy Falcon wrote:
We both know the smaller the function the less the increase in executable, so my statement isn't incorrect. But the increase is still substantial relative to the routine.
I did read your posts and have done so again when preparing this reply. Your assertion that, “if you call an inline function a lot, you'll increase the size of your exe substantially”, is simply not true for small functions. In fact the opposite is true: if the inline function is small then the more you call it the more space you’ll save! You’ve obviously interpreted my (correct) comments as a personal attack. This is not the case. The CodeProject is about sharing knowledge and such. I can see nowhere in you post to justify your assertion that you, “didn't deny your points on one-line routines.”
Steve
-
Stephen Hewitt wrote:
Macros make debugging harder and are not type safe.
Also, if you need a debugger for a one-line routine, let's just say you're better off being a Wal-Mart cashier. Let's get real man, you know that realistically speaking a one line routine isn't that big of a deal to debug. Or dare I say, just copy and paste the contents of the macro into a block and run it if you must and then put the modified code back into the macro. The benefits outweigh having to use two extra keystrokes IMO.
Jeremy Falcon "It's a good thing to do and a tasty way to do it." - Wilford Brimley[^]
Jeremy Falcon wrote:
Or dare I say, just copy and paste the contents of the macro into a block and run it if you must and then put the modified code back into the macro. The benefits outweigh having to use two extra keystrokes IMO.
Or just use
inlineand save yourself the hastle and enjoy type safety to boot!Steve
-
I was not (and am not) attempting to be pretentious. I said that your original statement about inline functions making functions bigger was “not true for really small functions.”:
Jeremy Falcon wrote:
Of course, if you call an inline function a lot, you'll increase the size of your exe substantially.
Stephen Hewitt wrote:
This is not true for really small functions. For example if a function simply added two numbers or returned some value then the function call overhead will be bigger then the actual code and inlining will save time and space.
To this you replied as follows:
Jeremy Falcon wrote:
We both know the smaller the function the less the increase in executable, so my statement isn't incorrect. But the increase is still substantial relative to the routine.
I did read your posts and have done so again when preparing this reply. Your assertion that, “if you call an inline function a lot, you'll increase the size of your exe substantially”, is simply not true for small functions. In fact the opposite is true: if the inline function is small then the more you call it the more space you’ll save! You’ve obviously interpreted my (correct) comments as a personal attack. This is not the case. The CodeProject is about sharing knowledge and such. I can see nowhere in you post to justify your assertion that you, “didn't deny your points on one-line routines.”
Steve
Stephen Hewitt wrote:
I said that your original statement about inline functions making functions bigger was “not true for really small functions.”:
You said that, and I said nothing to counter and yet you go on like I'm impressed or something.
Stephen Hewitt wrote:
I did read your posts and have done so again when preparing this reply. You assertion that, “if you call an inline function a lot, you'll increase the size of your exe substantially”, is simply not true for small functions. In fact the opposite is true: if the inline function is small then the more you call it the more space you’ll save!
My point that the increase is relative to the size of the routine wasn't disproved. Yet you say it is, that's incorrect and for no other reason that I can surmise expect you're just looking to argue and/or just don't listen. And yeah obviously, I wasn't talking about one-line routines at first, as I wouldn't do that, but I never denied your point on them. Which is why I find it odd you continue to press. I did say my statement was correct still however.
Stephen Hewitt wrote:
You’ve obviously interpreted my (correct) comments as a personal attack.
I think you need to look up the word pretentious.
Stephen Hewitt wrote:
I can see no where in you post to justify you assertion that you, “didn't deny your points on one-line routines.”
Really, well I don't see where I DID write one-line routines are bigger.
Jeremy Falcon "It's a good thing to do and a tasty way to do it." - Wilford Brimley[^]
-
Jeremy Falcon wrote:
Or dare I say, just copy and paste the contents of the macro into a block and run it if you must and then put the modified code back into the macro. The benefits outweigh having to use two extra keystrokes IMO.
Or just use
inlineand save yourself the hastle and enjoy type safety to boot!Steve
Stephen Hewitt wrote:
Or just use inline and save yourself the hastle and enjoy type safety to boot!
Ok, it's not much less type safe (way to miss a point again). And, save yourself two keystrokes for something rarely debugged in the first place and give yourself way more problems in exchange - yeah great advice.
Jeremy Falcon "It's a good thing to do and a tasty way to do it." - Wilford Brimley[^]
-
Stephen Hewitt wrote:
Or just use inline and save yourself the hastle and enjoy type safety to boot!
Ok, it's not much less type safe (way to miss a point again). And, save yourself two keystrokes for something rarely debugged in the first place and give yourself way more problems in exchange - yeah great advice.
Jeremy Falcon "It's a good thing to do and a tasty way to do it." - Wilford Brimley[^]
-
"The first rule about . . [macros] is: don't use them if you do not have to. . . almost every macro demonstrates a flaw in either the programming language or in the program." - Stroustrup
Having a truckload of simple inline functions to replace macros would demonstrate this same design flaw that he was referring to. Remember, if you understand what he was actually saying, it's not the macro itself itself that's the problem; it's the design flaw behind abusing it. Which is no better or worse than simply replacing it with an inline routine and leaving the same design.
Jeremy Falcon "It's a good thing to do and a tasty way to do it." - Wilford Brimley[^]
-
Having a truckload of simple inline functions to replace macros would demonstrate this same design flaw that he was referring to. Remember, if you understand what he was actually saying, it's not the macro itself itself that's the problem; it's the design flaw behind abusing it. Which is no better or worse than simply replacing it with an inline routine and leaving the same design.
Jeremy Falcon "It's a good thing to do and a tasty way to do it." - Wilford Brimley[^]
Jeremy Falcon wrote:
Having a truckload of simple inline functions to replace macros would demonstrate this same design flaw that he was referring to.
No it would not. I sugest you grab a copy of his book and read his comments in context. Also Scott Meyers addresses the issue in one of his books. Also this[^] discussion is relevant.
Jeremy Falcon wrote:
if you understand what he was actually saying
I pretty confident I have a good idea what he is getting at but if you think you know better than him or me macro away till the cows come home, I really dont care
-
Jeremy Falcon wrote:
Having a truckload of simple inline functions to replace macros would demonstrate this same design flaw that he was referring to.
No it would not. I sugest you grab a copy of his book and read his comments in context. Also Scott Meyers addresses the issue in one of his books. Also this[^] discussion is relevant.
Jeremy Falcon wrote:
if you understand what he was actually saying
I pretty confident I have a good idea what he is getting at but if you think you know better than him or me macro away till the cows come home, I really dont care
Josh Gray wrote:
Also this[^] discussion is relevant.
It's also confusing bad macro design with bad design in general. Apples to oranges.
Josh Gray wrote:
but if you think you know better than him or me macro away till the cows come home, I really dont care
Tell me then, since he designed C++, why didn't he drop macro support if he loathed the mere existence of them that much? Compatibility can't be the reason as it was a brand new language at the time, and wouldn't effect C. I can understand making it completely compile C code, but why not specify compilers replace macros with something else under the hood, etc. I mean, why keep them if they're so bad?
Jeremy Falcon "It's a good thing to do and a tasty way to do it." - Wilford Brimley[^]
-
Hi fellows I'm programming C++ approximately 1 1/2 year, and I programming for windows too. But some keywords I don't know exactly what they are and when I use them. That's my question: What the meaning of terms and when I use them: __stdcall __pascal __fastcall __thiscall inline It seems that's beginner question but I would like some answer to this question Thanks for help again
inline is the standout, it's different to the others. inline is a *suggestion* to the compiler that this function is so simple, that it's more efficient to write the code for this function in the places where it's called, instead of paying the cost of a call to another memory address to run it. The vital thing to understand is that hte compiler is both free to inline things itself, and to decide you're wrong and *not* inline the function.
Christian Graus - Microsoft MVP - C++ "I am working on a project that will convert a FORTRAN code to corresponding C++ code.I am not aware of FORTRAN syntax" ( spotted in the C++/CLI forum )
-
Stephen Hewitt wrote:
Or just use inline and save yourself the hastle and enjoy type safety to boot!
Ok, it's not much less type safe (way to miss a point again). And, save yourself two keystrokes for something rarely debugged in the first place and give yourself way more problems in exchange - yeah great advice.
Jeremy Falcon "It's a good thing to do and a tasty way to do it." - Wilford Brimley[^]
No, I'm not missing the point. Perhaps you can explain the advantages of macros over inline functions? There are some things inline functions can't do like stringisation and token pasting and such; but when inline functions can be used they're a better solution for many reasons including the following: - Type safety. - Automatically disabled in debug builds to aid debugging. - Can use multiline constructs without having to end each line with a "\". - Can be put into
namespaces! - Can be members ofclasses andstructs! - Can be overloaded! . . .Steve
-
No, I'm not missing the point. Perhaps you can explain the advantages of macros over inline functions? There are some things inline functions can't do like stringisation and token pasting and such; but when inline functions can be used they're a better solution for many reasons including the following: - Type safety. - Automatically disabled in debug builds to aid debugging. - Can use multiline constructs without having to end each line with a "\". - Can be put into
namespaces! - Can be members ofclasses andstructs! - Can be overloaded! . . .Steve
Stephen Hewitt wrote:
Perhaps you can explain the advantages of macros over inline functions?
Perhaps you can read my posts and find the answer there already seeing as I said it more than once.
Stephen Hewitt wrote:
- Type safety.
Addressed twice. The type safety you refer to isn't a real issue since a macro expands to type safe code.
Stephen Hewitt wrote:
- Automatically disabled in debug builds to aid debugging.
And like typing #ifdef _DEBUG will break your arm.
Stephen Hewitt wrote:
- Can use multiline constructs without having to end each line with a "\".
You know you're reaching deep when you have syntax as reasoning. :laugh:
Stephen Hewitt wrote:
- Can be put into namespaces! - Can be members of classes and structs. - Can be overloaded.
Actually these are very good points, but it doesn't really mean inline functions should always be used in place of macros as you suggest. Besides, this has contradicting logic. I mean, why write an inline function... usually for speed right? Using the second two of your three points quoted would effectively break that anyway.
Jeremy Falcon "It's a good thing to do and a tasty way to do it." - Wilford Brimley[^]
-
inline is the standout, it's different to the others. inline is a *suggestion* to the compiler that this function is so simple, that it's more efficient to write the code for this function in the places where it's called, instead of paying the cost of a call to another memory address to run it. The vital thing to understand is that hte compiler is both free to inline things itself, and to decide you're wrong and *not* inline the function.
Christian Graus - Microsoft MVP - C++ "I am working on a project that will convert a FORTRAN code to corresponding C++ code.I am not aware of FORTRAN syntax" ( spotted in the C++/CLI forum )
Christian Graus wrote:
inline is a *suggestion* to the compiler that this function is so simple
I hate to use your post, but that's a great reason I forgot. There is no real guarantee inline will even work. You're guaranteed to have inline expansion with macros though. Man, old age is getting to me. :-O
Jeremy Falcon "It's a good thing to do and a tasty way to do it." - Wilford Brimley[^]