What are the advantages and disadvantages of implementing classes in header files?

I love the concept of DRY (don't repeat yourself [oops]), yet C++'s concept of header files goes against this rule of programming. Is there any drawback to defining a class member entirely in the header? If it's right to do for templa开发者_如何学Ctes, why not for normal classes? I have some ideas for drawbacks and benefits, but what are yours?

---

Possible advantages of putting everything in header files:

• Less redundancy (which leads to easier changes, easier refactoring, etc.)
• May give compiler/linker better opportunities for optimization
• Often easier to incorporate into an existing project

Possible disadvantages of putting everything in header files:

• Longer compile/link cycles
• Loss of separation of interface and implementation
• Could lead to hard-to-resolve circular dependencies
• Lots of inlining could increase executable size
• Prevents binary compatibility of shared libraries/DLLs
• Upsets co-workers who prefer the traditional ways of using C++

---

Well - one problem is that typically implementations change much more often than class definitions - so for a large project you end up having to recompile the world for every small change.

---

The main reason not to implement a class in the header file is: do the consumers of your class need to know its implementation details? The answer is almost always no. They just want to know what interface they can use to interact with the class. Having the class implementation visible in the header makes it much more difficult to understand what this interface is.

Beyond considerations of compactness and separating interface from implementation, there are also commercial motivations. If you develop a library to sell, you (probably) do not want to give away the implementation details of the library you are selling.

---

You're not repeating yourself. You only write the code once in one header. It is repeated by the preprocessor, but that's not your problem, and it's not a violation of DRY.

If it's right to do for templates, why not for normal classes

It's not really that it's the right thing to do for templates. It's just the only one that really works in general.

Anyway, if you implement a class in a header, you get the following advantages and disadvantages:

• The full implementation is visible anywhere it is used, which makes it easy for the compiler to inline as necessary.
• The same code will be parsed and compiled multiple times, leading to higher compile-times.
• On the other hand, if everything is in headers, that may lead to fewer translation units, and so the compiler has to run fewer times. Ultimately, you might end up with a single translation unit, which just includes everything once, which can result in very fast compilations.

And... that's it, really.

Most of my code tends to be in headers, but that's because most of my code is templates.

---

The main disadvantage (apart from the lengthy builds) is there is no clear separation of the interface and implementation.

Ideally, you should not need to see the implementation of an intuitive, and well documented interface.

---

Not mentionned yet: virtual functions are instantiated for each include, so you can bloat your executable (I'm not sure whether this is true for all compilers).

There is an alternative:
Do a lot of stuff in classes declared in your source-file. 1 example is the pimpl-idiom, but there are also people who are afraid to declare classes out of the header-file. However, this makes sense for private classes.