Is it ok to declare/define a static method in the .cpp only?

Question

In many cases I find my classes needing private functions to break down their functionality and reuse code. The typical implementation would be :

MyClass.h

#include "AnotherClass.h"

class MyClass {
public:
    float foo() const;
private:
    float fooPrivate(const AnotherClass& ac) const; 
}

MyClass.cpp

#include "MyClass.h"

float MyClass::foo() const {
    return fooPrivate(AnotherClass());
}
float MyClass::fooPrivate(const AnotherClass& ac) const {
    return ac.foo();
}

This is ok, however declaring fooPrivate() in the header file can be problematic in the following cases :

we might not want to include AnotherClass in the header file if it is only for internal uses and is not needed outside MyClass.
if many private functions are needed we risk polluting the header file with unnecessary private functions that make code less clear, increase compile time and is more difficult to maintain.

I am aware of the Pimpl idiom that solves all these problems but my question is if we do not want to use the Pimpl is it ok to do something like this for a few functions ?

MyClass.h

class MyClass {
public:
    float foo() const;
}

MyClass.cpp

#include "MyClass.h"
#include "AnotherClass.h"

static float fooPrivate(const AnotherClass& ac) {
    return ac.foo();
}
float MyClass::foo() const {
    return fooPrivate(AnotherClass());
}

In this case it is not needed to include AnotherClass.h in MyClass.h and fooPrivate() can not be called by anyone except from inside MyClass.cpp and after it has been declared. Am I right?

Are there any caveats using this or will I end up with problems when my program gets bigger?

It seems to me that your private member function `fooPrivate` could have been static in the first place. Otherwise, your second approach would not work so well. — E_net4, Oct 19 '14 at 14:52
You know, a forward-declaration for `AnotherClass` is sufficient for the header. That's lightweight enough. — Deduplicator, Oct 19 '14 at 14:54
I understand you. However the point remains the same. Even if fooPrivate() uses some members of MyClass (which would make it non-static), there are many cases where a static function can be used to perform some stuff and then the results of the static call can be used to modify this class. — Konstantinos Gaitanis, Oct 19 '14 at 14:57
Forward declaration is also a form of polluting the header and needs update every time my private members are modified. It is lightweight though I agree. — Konstantinos Gaitanis, Oct 19 '14 at 14:59
Forward declaration pollutes the header a lot less than a full-blown type definition. — Lightness Races in Orbit, Oct 19 '14 at 15:02

Matthieu M. · Accepted Answer · 2017-09-11T12:02:43.537

16

Actually, not only is it okay, I would actually recommend it.

private functions may be used, and sometimes must (when accessing private elements) however there is one issue with them: even if it is only a declaration, they clutter the class definition: a user of the class should not have to care or be exposed to the class internals.

On the other hand, static functions or functions declared in an anonymous namespace within a source file are "free". No matter how many of them you have:

they do not clutter the header
on Itanium ABI compiler tool-chains (for example), they do not lead to an exported symbol, speeding up load time

If there is one downside, though, it is that on those same Itanium-related tool-chains their absence of name make for poor backtraces without debug symbols. It can be seen as a minor inconvenience though.

Note: not having access directly to private members of the class is rarely an issue because a method of the class can easily pass a reference to those members to them. It does mean they cannot build an instance of the class when the constructors are not public however.

edited Sep 11 '17 at 12:02

answered Oct 19 '14 at 15:08

Matthieu M.

287,565
48
449
722

1

+1 for the comment on debugging! This is by far the most clear answer. Thanks for your time. – Konstantinos Gaitanis Oct 19 '14 at 15:14
Which itanium related toolchains are you talking about? The Itanium itself is completely irrelevant nowadays, isn't it? – avl_sweden Sep 11 '17 at 10:27
1

@avl_sweden: I am talking about the (confusingly) [Itanium ABI](https://itanium-cxx-abi.github.io/cxx-abi/), which is the ABI used by Clang, GCC, ICC, ... – Matthieu M. Sep 11 '17 at 12:02
Ah, I see, didn't know it was called that! – avl_sweden Sep 11 '17 at 12:05
@avl_sweden: No worries; hopefully I've clarified the answer so that it's more obvious for everyone now :) – Matthieu M. Sep 11 '17 at 12:45

score 8 · Answer 2 · answered Oct 19 '14 at 14:55

8

There are no caveats, except slight inconvenience. Your static function is not going to be a class method, obviously. Because of that, it can only access public class members and methods.

answered Oct 19 '14 at 14:55

Sam Varshavchik

114,536
5
94
148

score 5 · Answer 3 · edited May 23 '17 at 12:02

5

I do this occasionally, for "helper functions" that have literally no use whatsoever in the class's public interface. I try to minimise the use of this pattern as there is no access to private variables. However, free functions are a good thing and arguably even increase encapsulation.

edited May 23 '17 at 12:02

Community

1
1

answered Oct 19 '14 at 15:01

Lightness Races in Orbit

378,754
76
643
1,055

score 4 · Answer 4 · answered Oct 19 '14 at 14:57

As your helper-function does only use the public interface of the class, using a static function only available in the classes implementation-file is fine.

Anyway, your example did not actually need the definition of AnotherClass, a lightweight forward-declaration would have been fine:

class AnotherClass;

Also, I would mark the function inline in both cases on general principles, iff it is used only by the implementation, and that is all together in the same translation-unit:
There would be a slight chance of better performance / smaller code, without any downsides.

Is it ok to declare/define a static method in the .cpp only?

4 Answers4