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 function have to do with the decision most of the time? Thanks in advance.
A:
A method is just a type of function that can access member variables. For example, the method and function below are equivalent:
class meep {
public:
int x;
int morp() { return x + 1; }
};
int morp2(meep *p) { return p->x + 1; }
Dietrich Epp
2009-06-08 23:36:05
Just for clarity.morp() is the methodmorp2() is the functionMethods exist inside a class or object while functions do not.
Mr. Pig
2009-06-08 23:37:51
I think the question was when to use what not what a member function is.
Piotr Dobrogost
2009-06-08 23:41:04
"Methods exist inside a class or object while functions do not." < In C++, there is no such thing as a "method", really. Both the things in this answer are functions, where one is a member function, and the other is a non-member function (free function). Calling one of them "method" serves for confusion (in fact, i wouldn't know what you meant - functions in the same namespace, member-functions, non-static members, ...?) and i encourage you to avoid that.
Johannes Schaub - litb
2009-06-09 01:13:25
+18
A:
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 :)
Piotr Dobrogost
2009-06-08 23:36:35
(+1). I also like this one by Scott Meyers: http://www.ddj.com/cpp/184401197 . Scott's and Herb's articles greatly complement each other, i think.
Johannes Schaub - litb
2009-06-09 01:04:10
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".
Laurence Gonsalves
2009-06-09 01:22:34
@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.
Johannes Schaub - litb
2009-06-09 01:36:19
A:
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.
Larry Watanabe
2009-06-09 00:03:08
A:
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.
Ryan Ginstrom
2009-06-09 00:58:14