Why/When static classes?

[Labdabeta]

Hello,

I noticed that in c++ everything that can be done using a static function in a class could be done by using a public function in the same namespace. Assuming that you bind your classes in a namespace these functions do not take up names in the global namespace. As such I was wondering when to use static functions in classes and when to use public functions. For an example here is the current situation where I cannot decide which to use:

class Sprite
{// private:
    //Some image data
    public:
    //some functions
    Sprite &applyPoints(vector<Coord2D> ps,Colour c);//applies the given colour to a set of points
    //Now I want to make it easy to draw bresenham lines without writing the algorithm yourself:
#ifdef STATIC_VERSION
    static vector<Coord2D> getLineCoords(Coord2D start,Coord2D end);
#else
    vector<Coord2D> getLineCoords(Coord2D start,Coord2D end);
#endif

When, if ever, is it appropriate to use the static version and when, if ever, is it appropriate to use the public version?

[pritaeas]

I'm not a fan of static classes/methods, but a common use is when building the singleton or factory pattern.

IMO static methods are often abused to mimic global functions, to avoid having to create a new object.

[Labdabeta]

Thats what I thought. Thanks.

[mike_2000_17]

Yeah, the most common use for static member functions is for factory functions, whether it is a straight-up "Create()" function to create an object of the class, or whether it is for a set of factory functions like "fromString" and stuff (i.e., Java-style conversion functions, when people are not familiar with or not comfortable with C++'s conversion operators, or they just want a more explicit syntax).

There are some other special purposes for static member functions. Most of the time, it just boils down to semantics. If a given function clearly and only belongs to the class, but it does not need to be called on an object of that class or does not take one (or more) as an argument to the function, then the only way to really tie it to the class is to make it a static member function. This is the same argument as for static data members.

And the name pollution can be a real concern sometimes. As a rule of thumb, if you have a class named "Foo" and you want to create a static member function named "Bar", and you are considering making that function a free-function (in the namespace/global scope) instead. If, while making the function a free-function, you would have to rename it to something like "FooBar" in order to make it make sense, then you are probably better off leaving it as a static member function, i.e., calling it as "Foo::Bar". This is the basic "semantics test" to figure out if Bar really meaningfully belongs to Foo. The language already gives you the scope-resolution operator (::) to express the "belonging" of things, so, don't shy away from it when it makes sense to use it.

That said, I agree that static member functions are very much abused in C++. This mostly comes from people whose minds have been polluted by horrible languages like Java or C#. Many people have been taught the simple rule of "if it doesn't need to be called on an object, then make it static". This rule works in Java, because that's the only option. In a multi-paradigm language like C++, there are many more choices. In basic terms, the hierarchy is as follows (from most desirable to least desirable):

1. Free functions (i.e., namespace / global scope)
2. Non-member friend functions (i.e., free functions that are befriended by a given class)
3. Static member functions
4. Member functions

The reason for preferring free functions is because they are free, literally. Free functions (friend or not) are subject to argument-dependent look-up of overloaded functions, making them the main conveyors of compile-time polymorphism. They are also more independent of the class's definition (or implementation), which promotes flexibility and modularity in the design, i.e., reducing inter-dependencies is always a good thing. And as for the static member functions, that's just a matter of applying the criteria that I explained at the start to know if it should not be a free function. And finally, non-static member functions are required for many things that are strongly coupled with the class' implementation and interface.

Oh, and I just want to mention, static member functions are also very useful in more advanced areas of C++ programming, expecially generic programming and template meta-programming. In this context, you can use a class as a kind of "bundle of functions", i.e., the class itself is often nothing more than an empty class with a bunch of static member functions. This not something you can do with namespace-scope functions. But this is a bit too advanced to discuss here.