C++ Member Functions vs Free Functions

Question

I keep on getting confused about this design decision a lot of the time when I'm writing programs, but I'm not 100% sure when I should make a function to be a member function of a class, when to leave it as a normal function in which other source files can call the function when the function declaration is exposed in a header file. Does the desired access to member variables of a class have to do with the decision most of the time?

Perfuse

Answer 1

The Interface Principle by Herb Sutter

For a class X, all functions, including free functions, that both
(a) "mention" X, and
(b) are "supplied with" X
are logically part of X, because they form part of the interface of X.

For in depth discussion read Namespaces and the Interface Principle by Herb Sutter.

EDIT
Actually, if you want to understand C++ go and read everything what Herb Sutter has written :)

Peltate

(+1). I also like this one by Scott Meyers: ddj.com/cpp/184401197 . Scott's and Herb's articles greatly complement each other, i think. – Enounce

I'm confused. The linked article is about namespaces, but the question isn't asking about namespaces. It's asking when to have "free functions" versus "member functions". – Sheba

@Laurence, well, Sutter's linked "What's in a Class" article explains the theoretical basis on why free functions are part of the interface of a class, and explains how Koenig Lookup is related to that "Interface Principle" (you need to click the [1] link on that linked article). But it doesn't explain when you should create free functions, and when not. That's why i linked the Meyer's article, which provides some good rules and rationals why you should generally prefer free functions. Together, they make perfect sense, i think. – Enounce

Is there a way to get (from an IDE or whatever) suggestions about all the functions that are part of a whole class interface as defined by Sutter? – Vinson

Answer 2

I use classes when I need to maintain state. If a function doesn't need access to maintained state information, then I prefer a free function because it makes testing and code reuse easier.

If I have a bunch of related functionality but don't need to maintain state, then I prefer putting free functions in a namespace.

Antediluvian

Answer 3

If something needs to access member variables or some aspect of an instance of the object, then it should be made a method.

If it is closely related to the class, but doesn't need to access any instance specific information, then it should be made a shared function (or class function, or static function depending on what programming language you are dealing with).

Even if it is just a generic function, chances are that you will have more than one of them and that they can be aggregated/organized according to some concept. Then, you can create a class representing that concept, and make them shared functions.

Given the above, I never see any reason to create standalone functions anymore.

Advection

C++ has no concept of methods. – Ability

method == member function – Harim

What is a "shared function"? C++ has no such concept AFAIK. Anyway, it's not recommended C++ style to use classes where not needed, including just as dumping grounds for functions. Free functions and namespaces are advised instead. This answer seems biased towards idioms or, ahem, forced design patterns from Other Languages, but the question is about C++. – Saltwort