Static member functions

Question

After reading sbi and Eli Bendersky's answers in this question I started to wondering what static member functions are for.

A class' friend free function shouldn't be able to do anything a static member function can do? If so, why/when should I prefer a static member function to a friend free one?

Answer 1

In general:

Require access to private members

static member functions have access to private members of the class. If you need that, you can use a static member function. You have to declare it in the header anyway to give it access, so you may as well make it a member rather than a friend. It is commonly done this way for singletons that have a getInstance() method as singleton, and classes that use a static factory method createInstance() to ensure they are created on the heap. Both of these need access to the private constructor.

Meta-programming

static member functions are very good for template meta-programming where you can pass in a class and call its method without knowing at the point of call what function will actually get invoked. This is commonly called "compile-time polymorphism" and is an important part of meta-programming. std::char_traits is based on this principle.

Restricted access

The common use of a private static member function, just so that it can be accessed only by the class, and does not itself need access to private members, is not a good use of static member functions because it is part of the implementation detail of the class, and this is better done in the anonymous namespace of the compilation unit.

However if the static member function is protected it has use as it can get called by derived classes but not by external classes.

friend functions

• Can have access to private members but need to be declared in the header anyway.
• Can be used in meta-programming as part of an "overload" however still needs to be declared in the header. (Common example is operator<< )
• Does not work for protected access with friendship as what you are trying to do here is restrict access to the method, not what the call has access to.

Answer 2

Static methods:

• Provide encapsulation in the "namespace" created by the class. If your class is Animal and the static method is Create , you have to call it with Animal::Create . This is better than global functions, and allow implementing Factories and "virtual constructors" with relatively natural syntax.
• Have access to static members. Such members are useful in some cases, and without static methods and members you would have to use global variables and functions.

Answer 3

Often, frankly, you shouldn't. Free functions are vastly under-rated.

The implicit "namespacing" you get from using a static member (pretending that the class is nothing more than a namespace for the static member, which is sort of true) is the only benefit that I can think of.

If the static function member needs persistent variables, the ability to have static data members along with it might also be useful.

Answer 4

Some people are wary of using static functions because it's often used by those who come from a procedural background and don't understand OO.

However there are many design patterns that make sense to be implemented using static member functions

For example. Singleton and Factory patterns to name a couple of the top my head, in fact most structural patterns that require object creation would require static member functions.

Answer 5

There is no added value to static member functions, as you correctly identified. Worse, when used for implementation details this introduce extra dependencies (in term of compilation).

The only use that could not be emulated with an anonymous free-function, is the protected access, that is, a derived class accessing a parent static function. However, this is never required: you can just make it a regular member function instead (I assume you don't have global state, otherwise the static/friend distinction is not of immediate concern).

The use of static functions in template meta-programming has been evoked... however it is very similar to the inner types issue: it makes it difficult to provide a default version. On the other hand, a suitably defined free function (which takes the type as a pointer), can propose a template version:

struct some_traits
{
  static void doStuff();
};

// versus

struct some_traits {};

void doStuff(some_traits*);

// and the default: void doStuff(...);

And of course, there is always the question of why this should be a static function, when a member function would provide more flexibility to the user. To this effect I would cite the move the Standard Committee made with the Allocator concept: stateful allocators are now authorized, which gives us the opportunity of packing the nodes of a given map in a same page rather than spreading them all over the heap.

Finally, there is the interface issue. However it's been a long time already since Sutter advocated that a class and the free functions defined in the same header both constituted the public interface of this class => that is what ADL is for! So it is more something to comfort ancient OO-programmers than a "good practice".

Really, I don't see any benefit from using static member functions. I would like people would think the contrary to propose real cases.