Archived

This topic is now archived and is closed to further replies.

simple inlining question

This topic is 5034 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

Recommended Posts

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.

Share on other sites
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

Share on other sites
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.

Share on other sites
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.

Share on other sites
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.

Share on other sites
So there''s no way to inline a function via the declaration?

Share on other sites
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 ...

Share on other sites
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

Share on other sites
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 fileint max( int a, int b );#ifndef _DEBUG    #inlcude "my.inl"#endif////////////////////////////////////////////////////// my.inl fileinlineint 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.

Share on other sites
But it should still recompile everything if you change anything.. There''s just no way around it, as others have pointed out already.

Share on other sites
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.

Share on other sites
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

Share on other sites
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.

Share on other sites
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.