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

Question

In many cases, I believe that my classes need private functions in order to destroy their functionality and code reuse. Typical implementation:

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 fine, 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 for internal purposes only and is not needed outside of MyClass.

• if many private functions are required, we risk polluting the header file with unnecessary private functions that make the code less clear, increase compilation time and more difficult to maintain.

I know about the Pimpl idiom that solves all these problems, but my question is whether we want to use Pimpl, is it normal to do something like this for several 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, you do not need to include AnotherClass.h in MyClass.h, and fooPrivate () cannot be called by anyone other than from MyClass.cpp and after its declaration. I'm right?

Are there any caveats using this or will I have problems with my program?

Answer 1

Actually, not only everything is in order, I would recommend it.

private can be used sometimes (when accessing private elements), but there is one problem with them: even if it is only an announcement, they clutter up the class definition: the user of the class should not have to be courted or exposed inside the class.

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

• they don't clutter the headline
• on Itanium ABI (e.g. compiler), they do not produce the exported character, speeding up loading time

If there is one drawback, however, precisely on the same Itanium-related toolchains, their lack of a name makes for poor backtracks without debugging symbols. This can be seen as a minor inconvenience.

Note. Without direct access to private , class members are rarely a problem, because a class method can easily pass a reference to these members. This means that they cannot build an instance of the class when the constructors are not publicly available.

Answer 2

There are no reservations except minor inconveniences. Obviously your static function will not be a class method. Because of this, it can only access public class members and methods.

Answer 3

I do this from time to time for "helper functions", which literally have nothing to do with the public interface of the class. I am trying to minimize the use of this template as there is no access to private variables. However, free features are a good thing and it is even possible to increase encapsulation .

Answer 4

Since your helper function uses only the public interface of the class, using a static function that is only available in class implementation files is great.

Anyway, your example doesn't really need a definition of AnotherClass , a light forward declaration would be fine:

 class AnotherClass; 

In addition, I would point out the inline function in both cases according to general principles, if it is used only for implementation, and all this together in the same translation unit:
There would be little chance of better performance / smaller code without any flaws.