Jump to content
  • Advertisement
Sign in to follow this  
okonomiyaki

Difference between implementing inside/outside class definition

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

If you intended to correct an error in the post then please contact us.

Recommended Posts

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?

Share this post


Link to post
Share on other sites
Advertisement
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.

Share this post


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

Share this post


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

Share this post


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

Share this post


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

Share this post


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

Share this post


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

Share this post


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

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!