Why do we put private member functions in headers?

Question

The answer to why we put private member variables in C++ headers is that the size of the class must be known at points where instances are declared so that the compiler can generate code that appropriately moves about the stack.

Why do we need to put private members in headers?

But is there any reason to declare private functions in the class definition?

The alternative would be essentially the pimpl idiom but without the superfluous indirection.

Is this language feature more than a historical error?

Answer 1

Private member functions may be virtual, and in common implementations of C++ (that use a vtable) the specific order and number of virtual functions is required to be known by all clients of the class. This applies even if one or more of the virtual member functions is private.

It might seem that this is like "putting the cart before the horse", because compiler implementation choices shouldn't affect the language specification. However, in reality the C++ language itself was developed at the same time as a working implementation (Cfront), which used vtables.

Answer 2

If you allowed methods to be added to a class outside its definition, they could be added anywhere, in any file, by anyone.

That would immediately give all client code trivial access to private and protected data members.

Once you've finished the class definition, there's no way to mark some files as being specially blessed by the author to extend it - there are just flat translation units. So, the only reasonable way to tell the compiler that a particular set of methods are official, or blessed by the class author, is to declare them inside the class.

---

Note that we have direct access to memory in C++, which means it's generally trivial to create a shadow type with the same memory layout as your class, add my own methods (or just make all the data public), and reinterpret_cast. Or I can find the code of your private function, or disassemble it. Or lookup the function address in the symbol table and call or directly.

These access specifiers don't try to prevent these attacks, because that isn't possible. They only indicate how a class is supposed to be used.

Answer 3

The accepted answer explains this for virtual private functions, but that only answers one specific facet of the question, which is considerably more limited than what the OP asked. So, we need to rephrase: Why are we required to declare non-virtual private functions in headers?

Another answer invokes the fact that classes must be declared in one block - after which they're sealed and cannot be added to. That's what you'd be doing by omitting to declare a private method in the header then trying to define it elsewhere. Nice point. Why should some users of the class be able to augment it in a way that other users can't observe? Private methods are part of it and aren't excluded from this. But then you ask why they're included, and it seems a bit tautological. Why must class users know about them? If they weren't visible, users couldn't add any, and hey presto.

So, I wanted to provide an answer that, rather than just including private methods by default, provides specific points in favour of having them visible to users. A mechanistic reason for non-virtual private functions requiring public declaration is given in Herb Sutter's GotW #100 about the Pimpl idiom as part of its rationale. I won't go on about Pimpl here, as I'm sure we all know about it. But here's the relevant bit:

In C++, when anything in a header file class definition changes, all users of that class must be recompiled – even if the only change was to the private class members that the users of the class cannot even access. This is because C++’s build model is based on textual inclusion, and because C++ assumes that callers know two main things about a class that can be affected by private members:

• Size and Layout: [of members and virtual functions - self-explanatory and great for performance, but not why we're here]
• Functions: The calling code must be able to resolve calls to member functions of the class, including inaccessible private functions that overload with nonprivate functions — if the private function is a better match, the calling code will fail to compile. (C++ took the deliberate design decision to perform overload resolution before accessibility checking for safety reasons. For example, it was felt that changing the accessibility of a function from private to public shouldn’t change the meaning of legal calling code.)

Sutter is, of course, an extremely reliable source as a member of the Committee, so he knows "a deliberate design decision" when he sees one. And the idea of requiring public declaration of private methods as a way to avoid altered semantics or accidentally broken accessibility later is probably the most convincing rationale. Thankfully, as the whole thing seemed rather pointless before now!

Answer 4

There are two reasons for doing this.

First, realize that the access specifier is for the compiler, and is not relevant at runtime. Accessing a private member outside of scope is a compile error.

Conciseness

Consider a function that is short, one or two lines. It exists to reduce the replication of code elsewhere, which also has the advantage of being able to change how an algorithm or whatever else works in one place instead of many (e.g. changing a sorting algorithm).

Would you rather have a quick one or two line in the header, or have the function prototype there plus an implementation somewhere? It is easier to find in the header, and for short functions, it is far more verbose to have a separate implementation.

There is another major advantage, which is...

Inline Functions

A private function may be able to be inlined, and this necessarily requires it to be in the header. Consider this:

class A {
  private:
    inline void myPrivateFunction() {
      ...
    }

  public:
    inline void somePublicFunction() {
      myPrivateFunction();
      ...
    }
};

The private function may be able to be inlined along with the public function. That is done at the compiler's discretion, as the inline keyword is technically a suggestion, not a requirement.

Answer 5

Another reason to have private methods in the header file: There are cases where a public inline method does not much more than calling one or several private methods. Having the private methods in the header means that a call to the public method can be completely inlined to the actual code of the private methods, and inlining doesn't stop with a call to the private method. Even from a different compilation unit (and public methods would usually be called from different compilation units).

Of course there's the reason as well that the compiler cannot detect problems with overload resolution if it doesn't know all methods, including private ones.

Answer 6

OTOH, private member functions aren't always necessary and none of the existing answers seem to speak to that.

I mean if you're just dealing with private member variables (and not things like needing access to private types), you can have your public member functions pass them as parameters to non-member, non-friend functions ("free functions" or even "pure functions") instead, and you can still be able to ensure that your class invariants are enforced. Then you can entirely do away with private member functions and having to have those declared in the header file with the class definition. As a side benefit, free/pure functions can be easier to unit test than private member functions. You can also define those functions within an anonymous namespace within a source file of your class's code and not need to have them declared in any header file at all. Similarly, one could also use lambda expressions with the same effect.

Of course the more private member variables a class uses, the more likely code will wind up passing an intolerable number of parameters this way (the C++ Core Guidelines I.23 suggests passing fewer than four). Then private member functions may look too convenient to pass up.

Arguably however, the more private member variables a class has, the more likely it's violating the single-responsibility principal. That suggests splitting apart the class into multiple smaller classes to reduce their individual number of responsibilities. This in turn would help avoid having to pass more parameters than desirable.

So while private member functions have to be declared in the class's definition per the language, neither the language nor encapsulation requires the use of private member functions to achieve the same end anyway.

Answer 7

It's to allow those functions to access the private members. Otherwise you'd need to friend them in the header anyway.

If any function could access the private members of the class then private would be useless.