If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

code in dot H files

An engineer just left our project and now I am working on his project. In his dot H files there are several routines where he writes the executable code in the declaration rather than the dot C or dot CPP file. For a method with maybe one line of code I don't see a real problem with that. However he has multiple methods written like this, one of which is over 150 lines of code. (Not a comment in sight but that is a different topic.)

Question:
Is there a possible advantage in writing the code in the dot H file rather than the dot CPP file?

Re: code in dot H files

Question:
Is there a possible advantage in writing the code in the dot H file rather than the dot CPP file?

Seems to me its better to put all the code in one place.

Originally Posted by bkelly

No, it is definately not template code.

Then I don't see any advantage in putting the implementation code in the dot H file.
Instead, there is a disadvantage: if you change something in the implementation being in .h file then all the cpp files that #include this header will be recompiled.

Re: code in dot H files

Inlining may not be an issue, All compilers take inlining as a hint only, any function that results in too much generated code bytes will simply not get inlined at all, even if it's in a .h file and even if you tried to force it with an inline or __inline or what your compiler offers in that area.

There is more to it than merely inlining however. By having the code in a .h the compiler is aware of what the fucntion does and may be able to simplify the code which may eventually lead to the compiler inserting only minor fragments of the 150line code. This can happen for highly branched code where the branches are taken ONLY based on parameter values (assuming they are POD types) of the function. Suppose something like;

With this code in a .cpp, all the compiler can do is generate calls to this function from any source other than the source where this function code resides.

With the above in a .h things get interesting.

With a call like foo(barvar, valvar); where barvar is a variable that the compiler cannot guarantee the value for, it will need to generate a function call, and have the entire function body in the executable as well.
However, a call like int i = foo(123,3); might very well be optimized to int i = 4;
and a call like int i = foo(4, valvar); might be optimised to int i = valvar/5;

Changing the function to a .cpp, could have devastating consequences for performance if such a function is 'called' inside performance critical code.

That programmer could be a C++ genious, he could be an idiot and even in this case, he could be an idiot that just happened to have done the right thing for the wrong reasons.

If you have no comments to go by stating that this needs to be in a .h for a particular reason, then functional analysis of if this would even do much being inlined/optimized or very detailed performance testing can reveal what's really going on.

Re: code in dot H files

If the function is small, then there is the slight advantage that the compile can 'inline' the function. However, I highly doubt the compiler can inline a function 150 lines long.

it won't inline 150lines of code. but...
it may optimize away most of those 150lines of code and only inline the bit it needs.

I have template functions (the fact they're templates really doesn't matter in this decision) that are much larger than 150lines, but where the compiler can extract only the short bit of code it needs when the function is 'called' with certain literal values.

* The Perfect Platform for Game Developers: Android
Developing rich, high performance Android games from the ground up is a daunting task. Intel has provided Android developers with a number of tools that can be leveraged by Android game developers.

* The Best Reasons to Target Windows 8
Learn some of the best reasons why you should seriously consider bringing your Android mobile development expertise to bear on the Windows 8 platform.