views:

5050

answers:

6

I have a class which has many small functons. By small functions, I mean functions that doesn't do any processing but just return a literal value. Something like

string Foo::method() const{
    return "A";
}

I have created a header file "Foo.h" and source file "Foo.cpp". But since the function is very small, I am thinking about putting it in the header file itself. I have the following questions

  1. Is there any performance or other issues if I put these function defnition in header file? I will have many functions like this.
  2. My understanding is when the compilation is done, compiler will expand the header file and place it where it is included. Is that correct?

Any help would be appreciated.

+3  A: 

There will be an increase in performance because implementation in header files are implicitly inlined. As you mentioned your functions are small, inline operation will be so beneficial for u imho.

What you say about compiler is also true.There is no difference for compiler --other than inlining-- between code in header file or cpp file.

Qubeuc
+1  A: 
  1. If your functions are that simple, make them inline, and you'll have to stick them in the header file anyway. Other than that, any conventions are just that - conventions.

  2. Yes, the compiler does expand the header file where it encounters the #include statements.

sykora
+3  A: 

If the function is small (the chance you would change it often is low), and if the function can be put into the header without including myriads of other headers (because your function depends on them), it is perfectly valid to do so. If you declare them extern inline, then the compiler is required to give it the same address for every compilation unit:

headera.h:

inline string method() {
    return something;
}

Class methods are implicit inline. The same stuff are true for them true: If they can be put into the header without hassle, you can indeed do so.

Because the code of the function is put into the header and visible, the compiler is able to inline calls to them, that is, putting code of the function directly at the call site (not so much because you put inline before it, but more because the compiler decides that way, though. Putting inline only is a hint to the compiler regarding that). That can result in a performance improvement, because the compiler now sees where arguments match variables local to the function, and where argument doesn't alias each other - and last but not least, function frame allocation isn't needed anymore.

My understanding is when the compilation is done, compiler will expand the header file and place it where it is included. Is that correct?

Yes, that is correct. The function will be defined in every place where you include its header. The compiler will care about putting only one instance of it into the resulting program, by eliminating the others.

Johannes Schaub - litb
Thanks. All this small functions are virtual. Will that makes any difference in inlining? And I think writing the function body in source file and marking as inline is better than writing directly in header. I am afraid, the header file will be less readable if all these functions are defined there.
Appu
if the compiler can find out the direction of a virtual function call, it can inline too: b *b_ = new d; doit(b_); // if it inlines doit, it will see that b_ is d. then it could inline the code of the virtual function definition as it is in d. virtual makes it more difficult, but not impossible
Johannes Schaub - litb
but i agree with you: i'm often relucant of putting the code into headers, because when i change it, it affects all the code having called it, and often defining in headers requires including at least one other header that the code depends on. (not always tho. for simple getters, i put them there).
Johannes Schaub - litb
The compiler will not inline virtual functions, the whole point of virtual functions is that they will be called through the class vtable, so they can be overriden.
Ismael
If you want inline functions that you can override then you should switch to templates.
Ismael
he was after whether it's theoretically possible, i think. and the compiler can do it, if it knows the dynamic type of the object pointed to at the point the call is made.
Johannes Schaub - litb
@xhantt - It is a rare occurence, but if the compiler knows an object's type at compile-time, it can inline virtual functions. I just verified this with GCC 4.3.2.
Tom
A: 

It depends on the coding standards that apply in your case but:

Small functions without loops and anything else should be inlined for better performance (but slightly larger code - important for some constrained or embedded applications).

If you have the body of the function in the header you will have it by default inline(d) (which is a good thing when it comes to speed).

Before the object file is created by the compiler the preprocessor is called (-E option for gcc) and the result is sent to the compiler which creates the object out of code.

So the shorter answer is:

-- Declaring functions in header is good for speed (but not for space) --

Iulian Şerbănoiu
A: 

You should use inline functions. Read this Inline Functions for a better understanding and the tradeoffs involved.

Naveen
+2  A: 

Depending on your compiler and it's settings it may do any of the following:

  • It may ignore the inline keyword (it is just a hint to the compiler, not a command) and generate stand-alone functions. It may do this if your functions exceed a compiler-dependent complexity threshold. e.g. too many nested loops.
  • It may decide than your stand-alone function is a good candidate for inline expansion.

In many cases, the compiler is in a much better position to determine if a function should be inlined than you are, so there is no point in second-guessing it. I like to use implicit inlining when a class has many small functions only because it's convenient to have the implementation right there in the class. This doesn't work so well for larger functions.

The other thing to keep in mind is that if you are exporting a class in a DLL/shared library (not a good idea IMHO, but people do it anyway) you need to be really careful with inline functions. If the compiler that built the DLL decides a function should be inlined you have a couple of potential problems:

  1. The compiler building the program using the DLL might decide to not inline the function so it will generate a symbol reference to a function that doesn't exist and the DLL will not load.
  2. If you update the DLL and change the inlined function, the client program will still be using the old version of that function since the function got inlined into the client code.
Ferruccio
Nice reply. Thanks :)BTW, my functions are virtual and will it make any difference when inline it?
Appu
Virtual functions cannot be inlined, they need to be referenced through a pointer in the vtable. I never tried it, but the compiler should either ignore the inline or complain about it.
Ferruccio
Virtual functions can be inlined if the type is known at compile time. That is very rare in practice.
Tom