CODEWITHSUNDEEP
c++cheader
dynamic
dynamic

Reputation: 48141

Is it still considered bad practice not to separate header from implementation?

Almost every language other than C and C++ doesn't separate headers from implementation. Is it still considered a bad practice to put the implementation of the functions/methods in the header file so you don't need to separate the two?

Example:

// File: myUtilLib.hpp

void myFunc1() {
  doSomething...
}

void myFunc2() {
  doSomething else...
}

Instead to have to copy/paste all the declaration in a separate .cpp file ?

Upvotes: 2

Views: 1302

Answers (3)

Rapptz
Rapptz

Reputation: 21317

Header-only libraries are not considered "bad" practice or "good" practices, they're a design decision that you as a writer have to consider with both its pros and cons. Multiple libraries do use the header-only approach and they're widely used in the industry such as Boost.

This is done with a combination of writing the inline (or constexpr, which are implicitly inline) keyword before the function definition to override the one-definition rule which states that two files cannot include the same symbol during compilation due to linker errors. This leads to "excessive inlining" despite the fact that the inline keyword does not actually force inlining. Classes and their methods are also implicitly inline (if you define them in the header), so having to put the keyword on those is unnecessary.

There are obvious drawbacks to the header-only approach, the most obvious being the increased compile times and the fact that you have multiple definitions of your code running about. However the easiest pro would be that you can just plop the header and it'll be easier to set up for you and possibly the user. It's a design decision that you have to take upon yourself.

Do note however that there are cases where header-only approach is the only approach, and this is in regards to templated code. There is a proposal for C++ to finally get modules that promises to make the build system less painful. However it hasn't been fully accepted but progress on it seems to be high on the importance scale.

Upvotes: 8

Mats Petersson
Mats Petersson

Reputation: 129504

There are several aspects on this.

First, the function HAS to be inline or only included once in the whole program, or you will get errors. And if the function is large, and the compiler decides to make an "out of line" copy, it may still be included more than once in the main executable, causing larger than necessary code.

Second, compile tile suffers if you keep doing this, because the same function is compiled multiple times.

Third, if the functions are quite large, and they are member functions, included within the class definition, then it becomes hard to get a good overview of the class content.

On the other hand, it's quite convenient to have all the stuff in one place, so there's an argument for still persevering, despite the above drawbacks. However, I don't personally think that it is enough of a benefit. Eventually, the files get large enough that they are unwieldy anyway, so you start splitting it.

Upvotes: 3

Keith Thompson
Keith Thompson

Reputation: 263557

Putting the implementation in the header isn't just bad practice, it doesn't work in most cases.

(Unless all your functions are defined as inline, but that's an unusual case.)

If more than one .cpp file has a #include for your header, you're going to have link-time errors due to multiple definitions of myFunc1 and myFunc2.

Upvotes: 1

Related Questions