Shall I make every function static, which do not touch the member variable?

Question

What is the Design and Performance impact for making all functions static which do not touch the member variable of the class?

Similar, but doesn't cover performance: http://stackoverflow.com/questions/6032096/static-function-leading-to-more-static-functions — Scott Langham, May 26 '11 at 08:19

score 9 · Accepted Answer · edited May 23 '17 at 12:04

9

You should actually consider making them non-static free functions, as explained in detail in this question. This question is also very interesting.

In a nutshell, these question explain that you should prefer non-friend non-member functions whenever possible (meaning when they do not access non-public members).

edited May 23 '17 at 12:04

Community

1
1

answered May 26 '11 at 08:02

Björn Pollex

75,346
28
201
283

I have to disagree, at least assuming that the OP is trying to follow object-oriented design patterns. Free functions just don't have a place in an object-oriented design. At the very least they can be grouped according to functional domain and implemented as members of all-static utility classes, along the lines of `StringUtils` and `SocketUtils` and so on. Just because the language allows you to have a function floating around arbitrarily with no logical container doesn't mean you should. – aroth May 26 '11 at 08:57
2

@aroth: Excuse my strong wording, but all-static utility classes are an atrocity. In C++ you have namespaces for just this thing. The idea that free functions have no place in OOP is just plain wrong, and the point that Java has several all static utility classes just proves that. Objects are for grouping *data and operations*, not for grouping just operations. – Björn Pollex May 26 '11 at 09:16
1

Interfaces should be able to be refactored across physical header files with minimal impact to client code, hence namespaces. That said, John Lakos has (surprise surprise) taken a contrary view promoting classes as scoping mechanisms precisely because they can't be reopened and extended, and hence unambiguously lead to a single physical file - something he consider(s/ed?) useful in enterprise environments. Staggering 8-/. If people on the C++ conference circuit can't agree (or won't unite against an unbalanced position), how can the average C++ programmer know what's good practice? – Tony Delroy May 26 '11 at 09:27
@aroth: the meaningful difference raised in this SO question is simply whether the functions are members of the class *they operate on*... if non-members are then grouped in a namespace or as static members in another class is a completely separate (hideous) question. – Tony Delroy May 26 '11 at 09:31
@Tony: Well spoken. There are many ways to look at the problem. In Python, for instance, classes actually are namespaces. And, the way you put it, I can even see the merits of all-static utility classes. Thanks for enlightening me! – Björn Pollex May 26 '11 at 09:33
@Space_COwbOy: Yup - even if all-static utility classes are 95% cons and 5% pros, it's still good to understand the trade-offs so you can get the best for your actual situation. Cheers. – Tony Delroy May 26 '11 at 09:36

Tony Delroy · Answer 2 · 2011-05-27T09:35:54.983

What are Design and Performance impact for making all function static which do not touch member variable of class?

performance: static member functions may be slightly faster than non-static member functions because they don't need to pass a this pointer, but you're unlikely to notice the difference; where inlining is used there may not be one. Further, pointers to a static function may be used directly, whereas "pointers" to non-static member functions are typically offsets/indices and require a this pointer for use; the run-time CPU operations involved can be expected to be slightly more complicated.

design: the choice between static and non-static member function can safely be made on the basis of the need to access an object's non-static member data in order to fully perform the expected operation. If you're generally comfortable with OOP and it doesn't seem intuitive and sensible to call the function using the notation object.fn(x, y, z) - that the function lends itself to being perceived as an operation on the current state of that specific object - then it probably shouldn't be a non-static member.

Ignoring the question as I understand it and looking at the wider terrain, free functions do have their own advantages as discussed in other replies; countering that the tighter association of static members can help programmers find potentially useful routines - all depending on the tools and habits they have.

score 2 · Answer 3 · answered May 26 '11 at 08:23

Performance-wise, static member functions are faster and use less stack space because they do not need to pass a this pointer. But this isn't a significant cost.

Regarding design, you should ask yourself why the functions are members of the class if they do not access its data members? There certainly are design patterns that include static functions. However, a widely favored approach to class design is to choose the minimum number of functions necessary to expose the functionality of the class while keeping its data hidden. This makes it easier to change the internals of the class without knock-on changes to the code which uses the class. Such an approach has little use for static functions as they cannot provide access to the data.

Alok Save · Answer 4 · 2011-05-26T08:27:17.747

0

Performance of static member functions vs free functions?
There is absolutely no performance difference between static member functions and free functions.

Performance of static member functions vs non static member functions?
Typically static member function are used to eliminate the need for an object and eliminate the extraneous this argument and that is the only performance advantage over non static member functions but it is hardly noticeable.

edited May 26 '11 at 08:27

answered May 26 '11 at 08:02

Alok Save

202,538
53
430
533

1

I think he asked about the difference between nonstatic members and static members. But there is none either given that the nonstatic must be nonvirtual to be considered at all for being changed to a static – Gunther Piez May 26 '11 at 08:06

score 0 · Answer 5 · answered May 26 '11 at 08:26

Absolutely yes. The non-static member functions are meant to cater the non-static member variables. If variables are not used then the function should be made static which makes your design cleaner and you can avoid passing this as the 1st hidden argument (which betters the performance a little).

[Note: On funny side there is one notable exception:

struct A {
  virtual void foo (int) = 0;
};

Even though you don't have member used inside foo() you can't make it static ! :)]

score 0 · Answer 6 · answered May 26 '11 at 08:27

Sometimes it makes sense to make a function virtual even if it does not access any instance members - for example to return some class-related properties (something like virtual bool eatsPlants() in the animal class hierarchy). Then it cannot be static because there are no virtual static members in C++.

score 0 · Answer 7 · answered May 26 '11 at 08:57

It depends. First, of course, if the function is to be virtual, then it can't be static. (Most of the member functions I have which don't touch a member variable are virtual. Otherwise, why make it a member at all?) Otherwise, it depends on the role of the function in the class. If it is fundamentally independent of any instance of the class (e.g. it sets some global parameter of the class, which affects all instances), then it should be static; such functions should be fairly rare, however. If on the other hand, it only incidental that it doesn't touch a member variable;, if conceptually, it does involve the specific instance, then make it a member. (This is frequent in the case of virtual functions, but probably very rare otherwise.)

Shall I make every function static, which do not touch the member variable?

7 Answers7