Skip to main content
gamedev.net
🔒 Locked

Difference between implementing inside/outside class definition

Started by okonomiyaki 7 replies 1.3k views
Original Post
okonomiyaki
okonomiyaki
I've always implemented small functions inside the class definition, and larger ones outside. What's the difference? between this: 

class foo {
    foo();

    something() {
         int a = 5;
         return a;
    }
}
and this: 

class foo {
     foo();

     something();
}

foo::something() {
     int a = 5;
     return a;
}
I've heard that implementations inside the class definition are automatically inlined. Is that true? Is that the only difference?
Miserable
Miserable
Yep, that's it. Since gratuitous inlining is not necessarily a good idea, I prefer to define my member functions outside of the class (and, of course, in a source file rather than the header). The fewer dependency difficulties, the better.
Trap
Trap
There is no semantic difference.

That said there is a difference in triggering recompiles or allowing inlining, depending on which compiler, build system or IDE is used.
okonomiyaki
okonomiyaki
I'm using VS.NET 2003 and I'm pretty sure it inlines implicity. Thanks for the confirmation. I don't really like things happening implicity either :p

Triggering recompiles is also a good point, I forgot about that. It wouldn't be a big deal, though, since I usually just put small functions in the class headers.
Teknofreek
Teknofreek
Quote:
Original post by okonomiyaki
Triggering recompiles is also a good point, I forgot about that. It wouldn't be a big deal, though, since I usually just put small functions in the class headers.


As far as recompiles go, it doesn't really matter if the functions are small or not. If you change what the function does then every other file that includes that header will need to be recompiled. If you change the function in the cpp file, then only that cpp file needs to be recompiled.

-John
John
Mayrel
Mayrel
Quote:
Original post by Teknofreek
Quote:
Original post by okonomiyaki
Triggering recompiles is also a good point, I forgot about that. It wouldn't be a big deal, though, since I usually just put small functions in the class headers.


As far as recompiles go, it doesn't really matter if the functions are small or not. If you change what the function does then every other file that includes that header will need to be recompiled. If you change the function in the cpp file, then only that cpp file needs to be recompiled.

Well, it kinda does matter. Small functions don't take so long to compile as long functions.
CoV
Washu
Washu
Semantically, there is no difference. Compile wise there can be many differences.

First off: functions which are inlined into the class decleration are implicitly marked inline. This doesn't mean that they WILL be inlined, just that the compiler is more likely to inline them.

Secondly: Change a function in the header and everyone who includes the header will have to recompile. It doesn't really matter how small the function is, or how small the change is, this is generally a bad thing. Especially when you get past a few kloc and compile times start to get longer and longer.

Thirdly: The linker (for modern compilers) can, and will, inline member functions if it decides that such an inline would be a good thing. So, just having it in a .cpp file doesn't automatically mean that it won't inline it.

Finally: Templates almost always have to be defined in the header they are declared in. Unless you are using comeau, which supports the export keyword.
In time the project grows, the ignorance of its devs it shows, with many a convoluted function, it plunges into deep compunction, the price of failure is high, Washu's mirth is nigh.
okonomiyaki
okonomiyaki
Quote:
Original post by Mayrel
Well, it kinda does matter. Small functions don't take so long to compile as long functions.


Quote:

It doesn't really matter how small the function is, or how small the change is, this is generally a bad thing.


I meant that because they are small functions, I won't be changing them at all (most likely just accessor functions); of course it doesn't matter how big the change is. :) I was worried about things going on in the background though, such as implicit inlining. I'll most likely keep all the code in the implementataion file but keep accessor functions in the declaration.

Thanks for the explanations Washu. I found that out about templating a while ago, and it's annoying.
iMalc
iMalc
Quote:
Original post by Mayrel
Quote:
Original post by Teknofreek
Quote:
Original post by okonomiyaki
Triggering recompiles is also a good point, I forgot about that. It wouldn't be a big deal, though, since I usually just put small functions in the class headers.


As far as recompiles go, it doesn't really matter if the functions are small or not. If you change what the function does then every other file that includes that header will need to be recompiled. If you change the function in the cpp file, then only that cpp file needs to be recompiled.

Well, it kinda does matter. Small functions don't take so long to compile as long functions.
Well yes it kinda does, but I guess his point was that the smaller the function is, the less likely that it will need to be changed at all. And if it really is that small, the more hints or allowances for any compiler to inline it, the better.

Of course if it's used in 100+ other cpp files you might want to reconsider.

Topic Locked

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

Sign in to reply to this topic.