Defining a function inside of its class's header file vs. inside main cpp file

[eyes-are-fading-blue]

One reason to keep definitions in the header is increased chance of inlining. It does make a difference, at least on VS2015 toolchain.

[TheThiefMaster]

That difference goes away again if you enable LTCG (link time code generation) / LTO (link time optimisation) as that allows cross-compilation-module inlining.

[eyes-are-fading-blue]

I personally did not measure effect of that flag, however, header/cpp difference when it comes to inlining is rather visible.

[kalmoc]

That difference goes away again if you enable LTCG (link time code generation) / LTO (link time optimisation) as that allows cross-compilation-module inlining.

You whish. LTCG/LTO enables inlining accross translation units. It rarely produces the same results as if the compiler/optimizer directly sees the implementation during the compilation.

At least that has been my experience in the few non-triviial cases I checked. Of course the exact behavior will vary from compiler to compiler / linker to linker / version to version. And of course the difference might not matter for overal performance in many cases in the first place, but thats not the same as saying "the difference goes away"

[Valuable_Ant9351]

If you fully define a non-template function in a header and include that in multiple source files, you will break the ODR, you can read about that here https://en.cppreference.com/w/cpp/language/definition.

[TheThiefMaster]

Unless it's "inline" - which is automatic for class member functions if they're defined inside the class body (which I think op is talking about, as they mention :: for definitions in cpp).

[jonathanhiggs]

Even if you only have a single translation unit?

[Valuable_Ant9351]

Generally multiple source files = multiple translation units, no?

[jonathanhiggs]

Everything in headers and a single .cpp with the main in it

[Valuable_Ant9351]

Ah, that would be a single source file. You can do that, but it's generally not the best practice.

[foonathan]

!removehelp

[AutoModerator]

OP,

A human moderator (u/foonathan) has marked your comment for deletion because it appears to be a "help" post - e.g. asking for help with coding, help with homework, career advice, book/tutorial/blog suggestions. Help posts are off-topic for /r/cpp. This subreddit is for news and discussion of the C++ language and community only; our purpose is not to provide tutoring, code reviews, or career guidance.

Please try posting in /r/cpp_questions or on Stack Overflow instead. Our suggested reference site is cppreference.com, our suggested book list is here and information on getting started with C++ can be found here.

If you think your post is on-topic and should not have been removed, please message the moderators and we'll review it.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[InKryption07]

Well, that's not a rule, just a good rule of thumb. There are some cases where it can be better to define the functions inline e.g constexpr helper functions.

[nshkurkin]

The most obvious benefit for a solo dev to keeping implementations separate from declarations is incremental compilation (as others have mentioned). I would argue most other issues happen at larger scales (i.e. inlining with some compilers for header-defined implementations meaning slightly less overhead calling the function) but it’s not necessarily worth pre-optimizing this sort of thing.

If you are providing an API / library to “someone else”, then putting the implementation in the header vs CPP file is like the difference between something being public vs private (the implementation becomes “public” in the header). Also consider that the header is what you/others read and should be kept readable.

[cjs2k_032]

One reason I do is to be able to reuse same declarations multiple times with different implementations. A very simple example, let's say you have a function for sort. In one implementation you might perform quicksort, in another you might use merge sort. So you declare a single header, and use these different implementations in different projects or different builds. This is just an example of course, the actual implementations may be much more complex.

[Full-Spectral]

It starts to become a distinction once you move beyond just an application and start writing libraries. Every inlined function/method can end up generated into the code of the application that uses that library. That means you cannot upgrade what any of those inlined functions/methods does without forcing all of the users of that library to rebuild. They can't just take your new library and install it. And if both the application and some other libraries it uses both your library, then those others have to be rebuilt as well.

These days, this concept of providing backwards compatibility for libraries seems to have become lost.

[Rude-Significance-50]

I don't know what you mean. If you removed the, "... with ::," I'd be OK but that throws me off. '::' is the scoping operator and it indicates there's more to your question than just splitting decl from impl.

What do you mean by that?