C / C++ / MFC

Jeremy Falcon wrote:

Of course, if you call an inline function a lot, you'll increase the size of your exe substantially.

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.

// 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;
}

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                   ret

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                   ret

Jeremy Falcon wrote:

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 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.

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.

Stephen Hewitt wrote:

I said that your original statement about inline functions making functions bigger was “not true for really small functions.”:

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!

Stephen Hewitt wrote:

You’ve obviously interpreted my (correct) comments as a personal attack.

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.”

Stephen Hewitt wrote:

Macros make debugging harder and are not type safe.

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.

Stephen Hewitt wrote:

Or just use inline and save yourself the hastle and enjoy type safety to boot!

Jeremy Falcon wrote:

Having a truckload of simple inline functions to replace macros would demonstrate this same design flaw that he was referring to.

Jeremy Falcon wrote:

if you understand what he was actually saying

Josh Gray wrote:

Also this[^] discussion is relevant.

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

Jeremy Falcon wrote:

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?

Josh Gray wrote:

Obviously I could only speculate at this and that would be pointless. It is my preference to avoid macros whenever possible.

Jeremy Falcon wrote:

if you don't hold it against me for sneaking the occasional macro or two in some code when you're not looking.

Stephen Hewitt wrote:

Perhaps you can explain the advantages of macros over inline functions?

Stephen Hewitt wrote:

- Type safety.

Stephen Hewitt wrote:

- Automatically disabled in debug builds to aid debugging.

Stephen Hewitt wrote:

- Can use multiline constructs without having to end each line with a "\".

Stephen Hewitt wrote:

- Can be put into namespaces!
- Can be members of classes and structs.
- Can be overloaded.

Stephen Hewitt wrote:

No one says macros should never be used, just that they shouldn’t be use when other superior constructs exist for the same task; the specific example in this case is that macros should not be used as inline functions.

Stephen Hewitt wrote:

I have constantly argued the point, complete with examples and data (compiler output) to support my claims;

Stephen Hewitt wrote:

while you seem intent on arguing the person and accusing people of missing the point. Well I've had my say and I'll let my comments speak for themselves.