Thread: inserting in a sorted list

Originally Posted by Daved

>> Prefer global functions to member functions if either will do the job.
>> Why?

It's better design. It keeps the class interface from becoming too bloated, and reduces dependencies on class internals.

See Item 44 in C++ Coding Standards (that is the book you would enjoy reading) for more information. It basically says the same thing- nonmember nonfriend functions minimize dependencies which improves encapsulation.

I looked at that item, and I don't think the reasons he gives for preferring non-member non-friend functions apply. Non-member functions that are friends are what compromise encapsulation--not adding an additional member function. As far as I can tell, the difference between a non-member non-friend function and member function is nil as far as encapsulation goes.

As for the reason that a class may get too bloated and therefore a member function should be made global if possible, that's doesn't strike me as a very compelling reason.

I don't really understand what practical difference it makes to declare the operator function global versus a member function. The author says the <string> class is an example of a bloated class which has 73 member functions some of which could be implemented as global functions. He says those functions would be more widely used if they hadn't been "buried in basic_string". I don't get that. Why would a function be more widely used if it were a global function rather than a member function?

I think you meant to say that the difference between non-member friend and member is nil in regards to encapsulation. I might agree with that. However, in the case of an operator, one advantage of making it a non-member (friend or not) is that implicit conversions will work on either side of the equation. A member function requires that the left-hand side be of the type that you are comparing. The best example is the string class. You can compare a string to a string literal like this: (str < "lit") or this: ("lit" < str). It seems like a trivial reason, but it is still a reason.

I'm not sure I agree with Sutter and Alexandrescu about the "bloated" theory on the member/non-member front either, at least in the case of operators. Non-member functions that work only on the specific class (such as operators) are really part of the class's interface as well. However, for other situations, often the function will be useful with other classes if given the correct level of abstraction. The algorithms are great examples of these. Obviously, a random_shuffle algorithm could have been added to the vector class, but it is much more effective as a non-member function that takes iterators, since now it can be used by any container supporting those types of iterators. Even simple things like empty() can be implemented as global methods, instead of being added to the specific interfaces of each class. There is a gotw article about the string class and why they feel it is too bloated. Obviously, it is subject to opinion, since the people who decided on that interface are pretty sharp themselves.

For friend vs non-friend, I think the distinction is obvious, and in this case it is the ultimate reason for making the operators non-members. By using the existing public interface to accomplish a task, you make it easier to change the implementation behind the interface in the future. If later on the getbegin() and getend() methods did more than just return the member variables, then the operators would not have to change and would continue to work.