tags:

views:

145

answers:

5

If I am creating a class with small functions that don't do much, is it acceptable to just put them all into the header file? So for a particular class, it's only just the .h with no .cpp to go with it.

+6  A: 

Yes, that's acceptable. It will certainly compile. But also, if it makes the code organization cleaner, then that can be good. Most template definitions are already like this out of necessity, so you aren't doing anything unheard of. There can be some drawbacks of that class relies on other classes though. If you end up having to include the whole definition in other files that use the class, it may incur additional compile time compared to only having a brief class declaration.

You can measure your compilation times if this seems to be a real concern.

If you can get a copy, The c++ Programming Language (and many other books) have a detailed section about source code organization and the specific benefits of separating code into .h and .cpp files.

JoshD
+2  A: 

Yes, it is acceptable. Moreover, if you do templates and you don't have a compiler with export support then you don't have a choice.

However, note that it can increase dependencies and thus make compilation slower.

ybungalobill
+1  A: 

It would be fine if you will use that header file in your future codes or projects, and if you want to share it with the others.

Ruel
A: 

Depends on how you're linking. To avoid having to see messages such as redefinition of blah, previous definition in file blah.h on line 13 just put everything but the declaration in a .cpp.

Novikov
+1  A: 

It depends what you are aiming for.

For a pet project, it's acceptable, but then anything is really.

For a real project, you need to ask yourself a number of questions:

  • do you have few dependencies ? (yes)
  • is your logic / implementation likely to change often ? (no, or see next question)
  • how much depends on this class ? (not much or much but it won't change)

If the responses satisfy you, then go ahead.

It is mainly a matter of dependency management. By putting the methods definition within the header, they are likely to get inlined by the compiler, which means that each time they change you'll have to recompile everything that depends on this class.

Templates do so, however templates generally have few dependencies (other includes) and you're relatively forced to proceed like so (though you can externalized non-template dependent code to cut down on dependencies).

For real big projects where dependency management is foremost, then I would advise against. In those projects a stable ABI and the ability to promote binary compatible changes are life-savers in case of issue and they are well worth the "slight" inconvenience for the developer.

In any case, please don't define the methods in the midst of the class. Even inlined you can define them after the class declaration. This makes it easier for people reading it (yourself in a few months) to get a grasp of the interface quickly.

Matthieu M.
IMO, if your methods are mostly one-liners, having method definition inside the class doesn't really distract much and can sometimes increases understandability of the code; and in fact the only reason why someone would not want to create a separate .cpp file is because the class is small and the methods are all trivial.
Lie Ryan
@Lie Ryan: I agree that one-liners (like `empty` / `size`) can be defined in the middle of the class without bothering one too much... but then it's difficult to define the limit between a one-liner, a one-liner that's wrapped because it didn't fit in the screen, a two-liners that is shorter than the wrapped one-liner, ... After that, it's everyone call.
Matthieu M.
@Matthieu: But you don't need to define a hard limit, just follow your gut feelings. In the end, the compiler would still produce the same or equivalent output. Many programming stylem guides promotes consistent style just because consistency is easy to quantify, if something always looks the same then it's consistent; however in many cases, this obsession for consistency is at the cost of ignoring potential benefits that is difficult to quantify. Readability and Understandability is not as easy to quantify; and as result, often get side-lined in style guidelines.
Lie Ryan