6

Should you declare the getters/setters of the class inside the .h file and then define them in .cpp Or do both in .h file. Which style do you prefer and why? I personally like the latter wherein all of them are in .h and only methods which have logic associated with it other than setters/getters in .cpp.

BalusC
  • 992,635
  • 352
  • 3,478
  • 3,452
kal
  • 26,197
  • 48
  • 119
  • 147

8 Answers8

12

For me it depends on who's going to be using the .h file. If it's a file largely internal to a module, then I tend to put the tiny methods in the header. If it's a more external header file that presents a more fixed API, then I'll put everything in the .cpp files. In this case, I'll often use the PIMPL Idiom for a full compilation firewall.

The trade-offs I see with putting them in the headers are:

  • Less typing
  • Easier inlining for the compiler (although compilers can sometimes do inlining between multiple translation units now anyway.)
  • More compilation dependencies
Community
  • 1
  • 1
Eclipse
  • 42,854
  • 19
  • 110
  • 166
8

I would say that header files should be about interface, not implementation. I'd put them in the .cpp.

duffymo
  • 293,097
  • 41
  • 348
  • 541
4

For me this depends on what I'm doing with the code. For code that I want maintained and to last over time, I put everything in the .cc file for the following reasons:

  • The .h file can remain sparse as documentation for people who want to look for function and method definitions.
  • My group's coding guidelines state that we put everything in the .cpp file and like to follow those, even if the function definition only takes one line. This eliminates guessing games about where things actually live, because you know which file you should examine.
  • If you're doing frequent recompiles of a big project, keeping the function definition in the .cpp file saves you some time compared to keeping function definitions in header files. This was relevant very recently for us, as we recently went through the code and added a lot of runtime assert statements to validate input data for our classes, and that required a lot of modification to getters and setters. If these method declarations had lived in .cpp files, this would have turned into a clean recompile for us, which can take ~30min on my laptop.

That's not to say that I don't play fast-and-dirty with the rules occasionally and put things in .h files when implementing something really fast, but for code I'm serious about I all code (regardless of length) in the .cpp file. For big projects (some of) the rules are there for a reason, and following them can be a virtue.

Speaking of which, I just thought of yet another Perl script I can hack together to find violations of the coding guidelines. It's good to be popular. :)

James Thompson
  • 43,044
  • 17
  • 61
  • 80
2

I put put all single-liners in the header as long as they do not require too much additional headers included (because calling methods of other classes). Also I do not try to put all code in one line so I can put most of the methods in the header :-)

But Josh mentioned a good reason to put them in the .cpp anyway: if the header is for external use.

mmmmmmmm
  • 14,543
  • 2
  • 28
  • 53
2

I prefer to keep the .h file as clean as possible. Therefore, small functions that are as simple as get/set I often use to put in a separate file as inline-defined functions, and then include that file (where I use the extension .inl) into the .h header file:

// foo.h

class foo
{
public:
   int bar() const;

private:
   int m_bar;
};

#include "foo.inl"

// foo.inl

inline
int foo::bar() const
{
   return m_bar;
}

I think that this gives the best of two worlds, at the same time hiding most of the implementation from the header, and still keep the advantage of inlining simple code (as a rule of thumb I keep it within at most 3 statements).

Stefan Rådström
  • 815
  • 6
  • 7
  • "Hiding from goto-zealots" is more like it. In my limited experience, there can be LOTS of those bar() { return m_bar; } "getters", so you are adding clutter to no benefit. A member-ref is VERY different in performance from any kind of actual calculation, do you want to hide that really ? – pngaz Jan 25 '09 at 08:27
1

I pretty much always follow the division of declaring them in the header, and defining in the source. Every time I don't, I end up having to go back and do it any way later.

Adam
  • 24,261
  • 23
  • 72
  • 87
1

I prefer to put them into the .cpp file, for the sake of fast compile/link times. Even tiny one-liners (empty virtual destructors!) can blow up your compile times, if they are instantiated a lot. In one project, I could cut the compile time by a few seconds by moving all virtual destructors into the .cpp files.

Since then, I'm sold on this, and I would only put them into the header again if a profiler tells me that I can profit from inlining. Only downside is you need more typing, but if you create the .cpp file while you write the header, you can often just copy&paste the declarations and fill them out in the .cpp file, so it's not that bad. Worse of course if you later find out you want to move stuff into a .cpp file.

A nice side effect is that reading stuff is simpler when you have only documentation and declarations in your header, especially if new developers join the project.

Anteru
  • 18,283
  • 10
  • 72
  • 117
0

I use next rule: header for declaration, code file for realization. It becomes for actual when your header would be use outside of project - than more lightweight your header is, then it's more comfort in use

abatishchev
  • 92,232
  • 78
  • 284
  • 421