Skip to main content
GameDev.net gamedev.net
🔒 Locked

simple inlining question

Started by Damocles May 7, 2004 at 6:58 AM 13 replies 1.1k views
Original Post
Damocles
Damocles
This is bugging me - it''s one of those things that I feel I should know by now, but when I come to try it, I realise I don''t know The question is - how do you inline a non member function? I have a function declared in a regular cpp file that I would like to make inlined into every call made to it. I guess I could macro it, but I figure there has to be a way to tell the compiler to inline it. If I try, it generates linker errors. I''m using VC6 if it makes a difference.
------------------------------------------[New Delta Games] | [Sliders]
markr
markr
You should be able to define an inline function, and have it inlined provided:

1. You define it in a .h file rather than a .cpp file
2. You don''t try to take the address of it

I haven''t actually tried, but as far as I''m aware, it works exactly like inline member functions.

Mark
Jingo
Jingo
inline is just a hint to the compiler, it doesn''t actually have to listen to it. You use it like this:


inline int max( int a , int b )
{
return a > b ? a : b;
}
int main()
{
max(5,6);
}


VC++ 2003.net has a microsoft specific keyword to force inlining, __forceinline, not sure if it is implemented in VC++6.
Damocles
Damocles
Yeah, there''s the kicker - I want to keep the declaration in a header file and the body in a cpp file.

I maintain a globals.h header file that contains the declarations for all global variables and functions which then gets included in almost every new class/file. Saves a lot of time with not having to include a million different headers.
The problem is, if I keep the inlined functions in the header file, then any time I want to make minor changes to the functions, I will have to recompile 90% of the project which takes ages. If I can find a way to keep them in a seperate file then I only have to recompile that file.
------------------------------------------[New Delta Games] | [Sliders]
Jingo
Jingo
Well every translation unit will need the definition of the function in order to compile and inline the code, you wont be able to split the function definition and calls across multiple translation units and use inlining.
Damocles
Damocles
So there''s no way to inline a function via the declaration?
------------------------------------------[New Delta Games] | [Sliders]
Miserable
Miserable
quote:
Original post by Damocles
Yeah, there''s the kicker - I want to keep the declaration in a header file and the body in a cpp file.

I maintain a globals.h header file that contains the declarations for all global variables and functions which then gets included in almost every new class/file. Saves a lot of time with not having to include a million different headers.
The problem is, if I keep the inlined functions in the header file, then any time I want to make minor changes to the functions, I will have to recompile 90% of the project which takes ages. If I can find a way to keep them in a seperate file then I only have to recompile that file.

You must have missed the point of inline functions, which is that their body gets pasted into the caller code to avoid the cost of setting up a function call, returnin, et cetera. Unfortunately, if the function''s body is pasted into the calling code, then obviously anything that calls it must be recompiled every time it changes ...
markr
markr
quote:
The problem is, if I keep the inlined functions in the header file, then any time I want to make minor changes to the functions, I will have to recompile 90% of the project which takes ages. If I can find a way to keep them in a seperate file then I only have to recompile that file.


That''s the only way you can do it I''m afraid.

However it should not happen too often, because your inlined functions should not include too much code, this may cause slower or bigger code, or cause the compiler to choose not to inline them (in which case there''s no point).

Mark
simba
simba
quote:
Original post by Damocles
Yeah, there''s the kicker - I want to keep the declaration in a header file and the body in a cpp file.

I maintain a globals.h header file that contains the declarations for all global variables and functions which then gets included in almost every new class/file. Saves a lot of time with not having to include a million different headers.
The problem is, if I keep the inlined functions in the header file, then any time I want to make minor changes to the functions, I will have to recompile 90% of the project which takes ages. If I can find a way to keep them in a seperate file then I only have to recompile that file.


One thing you might be able to do, which I do quite frequently for inlined class member functions, is to define the function body in a .inl file. Then in debug mode included it in a .cpp file so it''s not inlined but in release I include it in the .h file. Something like:



//////////////////////////////////////////////////////

// some header file


int max( int a, int b );

#ifndef _DEBUG
#inlcude "my.inl"
#endif

////////////////////////////////////////////////////

// my.inl file


inline
int max( int a, int b )
{
return a > b ? a : b;
}

////////////////////////////////////////////////////

// notinl.cpp file


#ifdef _DEBUG
#include "my.inl"
#endif



I think this should work. Don''t know that I''ve ever tried it for non class member function, but it definately works for class member functions.
Wuntvor
Wuntvor
But it should still recompile everything if you change anything.. There''s just no way around it, as others have pointed out already.
mattnewport
mattnewport
If you get the free VC 7.1 compiler from MS and turn on whole program optimization then it can inline functions from .cpp files (if the optimizer decides it''s worthwhile). That happens outside your control though - you still can''t declare the function as inline in the .h and put the definition in the .cpp and use it from another translation unit without linker errors.
Neophyte
Neophyte
It''s actually possible to inline a function even if it''s only declared in a header-file, and defined in a source-file. All of this is highly dependant on compiler/linker/platform and I have no idea which systems support link-time inlining. If you want to see if your system supports link-time inlining write a simple test and check the assembly code.

Thinking that inlining can only happen at compile-time (implying that the actual implementing code must be available to all compilation units) is a fairly common mistaken; in fact inlining can happen at compile-time, link-time, install-time and run-time.

- Neophyte
simba
simba
quote:
Original post by Wuntvor
But it should still recompile everything if you change anything.. There''s just no way around it, as others have pointed out already.


Hmm... not sure if you were refering to my earlier post or not, but as I set it up in will only recompile everything in release, because it''s not actually inlined in debug. Since so much work is actually done in debug it does provide a bit of compile time relief.
bytecoder
bytecoder
quote:

The problem is, if I keep the inlined functions in the header file, then any time I want to make minor changes to the functions, I will have to recompile 90% of the project which takes ages. If I can find a way to keep them in a seperate file then I only have to recompile that file.


The problem''s right here:
quote:

I maintain a globals.h header file that contains the declarations for all global variables and functions which then gets included in almost every new class/file.


Include only the things that you need. Sure it might be faster to just #include every header in one master header file in the short run, but in the long run it''s going to cause a lot of trouble, as you have already seen.

Ofcourse none of this should be necessary, as any modern language has compilation units, not header files. I don''t even use C or C++ anymore for the project specific code anymore; I either use python, or in the future I''ll use the lisp scripting module in the engine I plan on making.

The main reason C is still used is so that functions can be accessed from different languages; there''s no way to reliably interface to C++ code and be compiler independent due to name mangling.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.