C++, do private functions really need to be in the header file?

Question

I have always thought of header files as a sort of 'public interface' describing a class, in which case it would be better to keep private fields and functions in the cpp file.

I understand that private fields need to be in the header so that other classes can tell how much memory an instance of a class will consume, but it occurred to me as I was about to write a private helper function, that this function could be made static, in which case there was no need for it to be 'part of the class' at all, it could just as easily be a regular function in the class definition's .cpp file.

It then occurred to me that all private functions could potentially be re-written to be static by accepting pointers/references to class fields instead of expecting to be defined in the class.

This would eliminate the need to declare any private functions in the header file.

I do like to follow conventions so now I want to ask, is it considered an established convention in C++, that non-static private functions should be in the header file? What about static functions or static constants?

EDIT: I'm going to put in some code to explain what I'm getting at:

.h file:

#ifndef SOME_CLASS_H
#define SOME_CLASS_H

class SomeClass
{
private:
    int x;
public:
    void combineWithX(int y);
};

#endif

.cpp file

#include "SomeClass.h"

void someHelper(int* x)
{
    *x = (*x) + 1;
}

void SomeClass::combineWithX(int y)
{
    someHelper(&x);
    x += y;
}

Note that someHelper(int* x) in the cpp file references the private member x in spirit, but not directly, and therefore does not need to appear in the header. I'm wondering if this sort of thing is considered 'bad style'

Note that the private functions would need to be friended from inside the class, or else they couldn't access private members. If they don't need private members, maybe those functions shouldn't themselves be members at all. — Mooing Duck, Feb 05 '15 at 01:03
Since you cannot reopen a class for expansion once closed (C++11 9.2-p2), yes, your member functions *and* member vars *of that class* have to be mated in its decl. You can certainly do a [pimpl](http://stackoverflow.com/questions/843389/the-pimpl-idiom-in-practice)-implementation if desired. — WhozCraig, Feb 05 '15 at 01:05
@WhozCraig thanks, I borrowed your link (originally I linked to a worse question) — M.M, Feb 05 '15 at 01:13
@MooingDuck private functions can be put inside a private inner class, this way they don't have to be in header. https://stackoverflow.com/a/28734794/463758 — balki, Aug 03 '17 at 16:10
See thes answers for meaningful explanations *why* private functions (even if they are static or non-virtual) have to appear in the class declaration: https://softwareengineering.stackexchange.com/a/239175/221200 https://softwareengineering.stackexchange.com/a/324450/221200 — jcsahnwaldt Reinstate Monica, Feb 10 '19 at 14:27

balki · Answer 1 · 2022-01-27T15:45:03.843

35

Private helper functions can be hidden from public header file by moving them to an inner class. This works because inner class is considered part of the class and can access the surrounding class's private members.

Unlike PImpl idiom, this does not have any dynamic allocation or indirection penalty. Compile times should be faster when editing/refactoring private functions, as there is no need to recompile all the files including the public header.

Example:

public .h file

#ifndef SOME_CLASS_H
#define SOME_CLASS_H

class SomeClass
{
private:
    // Just forward declaring in public header.
    struct Private;
    int x;
public:
    void combineWithX(int y);
};

#endif

in .cpp file

#include "SomeClass.h"

// Declare all private member functions of SomeClass here
struct SomeClass::Private
{
  static void someHelper(SomeClass& self)
  {
    self.x = self.x + 1;
  }
};

void SomeClass::combineWithX(int y)
{
    Private::someHelper(*this);
    x += y;
}

edited Jan 27 '22 at 15:45

answered Feb 26 '15 at 05:02

balki

24,438
28
97
142

2

Doesn't `Private` need to be declared as a friend in order for it to access private members of `SomeClass`? `friend struct Private`. I just checked if your code compiles and it does, but I don't understand why. A normal nested class/struct doesn't get any special permissions of its enclosing class. – GameSalutes Dec 31 '18 at 23:19
@GameSalutes I don't have the std reference, but this has always worked without any warnings. So I guess, nested struct does get full access to the enclosing struct as if it is part of it without having to mark it as `friend` – balki Dec 31 '18 at 23:35
5

I see I was mixing up my scoping rules. Turns out a nested class has same access level restrictions as other data members defined so it can access the private members of the enclosing class. What I was thinking of was the converse that the enclosing class cannot access the nested class internals. This is guaranteed by standard (cpp17 n4659) - 12.2.5 covering nested class declarations both the forward declaration and the access allowances. A great forum post: http://www.cplusplus.com/forum/general/181016/ Going to make use of this as it better encapsulates private member functions – GameSalutes Jan 02 '19 at 07:22
So we don't need to declare private functions in the header file but we need to declare `Private`... doesn't it end up being the same? – devoured elysium Nov 21 '21 at 17:32
1

@devouredelysium The main advantage is you don't have to change header file when you want to add/remove/modify private functions and so no need to recompile all the files that includes this header. – balki Dec 08 '21 at 15:28
@devouredelysium, in the example it would seem like there isn't much benefit, but imagine having 5 or more private methods - you still only need to write `struct Private` once. You can add/minus methods as you please - change the interface or behaviour of those methods without triggering a recompile - and it helps to keep the data and the public methods nice and clear in the header. – Elliott Jun 05 '22 at 07:06

score 16 · Accepted Answer · edited May 23 '17 at 12:09

16

I agree that it is a problem that implementation details need to be exposed in a header file; it interferes with separation of interface and implementation.

Moving private helper functions to be free functions in the .cpp file (I presume that is what you meant by "static") won't work if those functions need to access private member variables.

You may be interested to look at the pImpl idiom (more)

edited May 23 '17 at 12:09

Community

1
1

answered Feb 05 '15 at 01:05

M.M

134,614
21
188
335

"won't work if those functions need to access private member variables" that's unfortunate. Languages like Go make private variables module-based rather than class-based, makes much more sense IMO. And private helper functions would be possible in C++ if this was also the case. – David Callanan Aug 20 '21 at 11:31

score -1 · Answer 3 · answered Sep 09 '20 at 18:37

How about

// MyClass.h -

MyClass {
public:
   // public stuff..

#ifdef mynamespace_myclass_p
private:
   // private stuff..
#endif // mynamespace_myclass_p

}

// MyClass.cpp - 

#define mynamespace_myclass_p
#include "MyClass.h"

// implementation code..

Eh, but then your headers are still cluttered with private stuff.

Headers are such a pain. I might be wrong, but at the moment I sort of feel that headers are the thing with the biggest pain / usefulness ratio in all of C++. You basically have to maintain all your method signatures in at least two places when you program in C++, and if you don't want your public headers cluttered with private stuff, you pretty much have to have 2 versions of your headers, which means maintaining your signatures in at least 3 places! Plus any forward declares that turn out to be needed. Seriously, they're so much more trouble than they're worth.

I'm really looking forward to seeing how C++20's module system plays out. It could be a huge boon. We've been waiting for it for almost 5 decades.

C++, do private functions really need to be in the header file?

3 Answers3

Linked