tags:

views:

1159

answers:

9

i like to use static functions in c++ as a way to categorize them, like c# does.

Console::WriteLine("hello")

but is it good or bad ? if the functions are often used i guess it doesn't matter, but if not do they put pressure on memory ?

The same goes for static const...

+7  A: 

I'm all for using static functions. These just make sense especially when organized into modules (static class in C#).

However, the moment those functions need some kind of external (non compile-time const) data, then that function should be made an instance method and encapsulated along with its data into a class.

In a nutshell: static functions ok, static data bad.

Frank Krueger
+1  A: 

Agree with Frank here, there's not a problem with static (global) functions (of course providing they are organised).. The problems only start to really creep in when people think "oh I will just make the scope on this bit of data a little wider".. Slippery slope :)

To put it really into perspective.. Functional Programming ;)

Rob Cooper
+1  A: 

One specific reason static data is bad, is that C++ makes no guarantees about initialization order of static objects in different translation units. In practice this can cause problems when one object depends on another in a different translation unit. Scott Meyers discusses this in Item 26 of his book More Effective C++.

Brian Stewart
+1  A: 

I tend to make classes that consist of static functions, but some say the "right way" to do this is usually to use namespaces instead. (I developed my habits before C++ had namespaces.)

BTW, if you have a class that consists only of static data and functions, you should declare the constructor to be private, so nobody tries to instantiate it. (This is one of the reasons some argue to use namespaces rather than classes.)

Kristopher Johnson
+15  A: 

but is it good or bad

The first adjective that comes to mind is "unnecessary". C++ has free functions and namespaces, so why would you need to make them static functions in a class?

The use of static methods in uninstantiable classes in C# and Java is a workaround because those languages don't have free functions (that is, functions that reside directly in the namespace, rather than as part of a class). C++ doesn't have that flaw. Just use a namespace.

DrPizza
I agree. +1. "static" methods could have their use, but I'm unable to provide one, or to find one in all the posts, that is not already covered by namespaces. GO NAMESPACES. :-)
paercebal
+1  A: 

The problem with static functions is that they can lead to a design that breaks encapsulation. For example, if you find yourself writing something like:

public class TotalManager
{
    public double getTotal(Hamburger burger)
    {
        return burger.getPrice() + burget.getTax();
    }
}

...then you might need to rethink your design. Static functions often require you to use setters and getters which clutter a Class's API and makes things more complicated in general. In my example, it might be better to remove Hamburger's getters and just move the getTotal() class into Hamburger itself.

Outlaw Programmer
+1  A: 

Use namespaces to make a collection of functions:

namespace Console {
    void WriteLine(...) // ...
}

As for memory, functions use the same amount outside a function, as a static member function or in a namespace. That is: no memory other that the code itself.

Johannes Hoff
A: 

For organization, use namespaces as already stated.

For global data I like to use the singleton pattern because it helps with the problem of the unknown initialization order of static objects. In other words, if you use the object as a singleton it is guaranteed to be initialized when its used.

Also be sure that your static functions are stateless so that they are thread safe.

KannoN
A: 

I usually only use statics in conjunction with the friend system.

For example, I have a class which uses a lot of (inlined) internal helper functions to calculate stuff, including operations on private data.

This, of course, increases the number of functions the class interface has. To get rid of that, I declare a helper class in the original classes .cpp file (and thus unseen to the outside world), make it a friend of the original class, and then move the old helper functions into static (inline) member functions of the helper class, passing the old class per reference in addition to the old parameters.

This keeps the interface slim and doesn't require a big listing of free friend functions. Inlining also works nicely, so I'm not completely against static. (I avoid it as much as I can, but using it like this, I like to do.)

Erius