c++ - Class design vs. IDE: Are nonmember nonfriend functions really worth it?

Question

In the (otherwise) excellent book C++ Coding Standards, Item 44, titled "Prefer writing nonmember nonfriend functions", Sutter and Alexandrescu recommend that only functions that really need access to the members of a class be themselves members of that class. All other operations which can be written by using only member functions should not be part of the class. They should be nonmembers and nonfriends. The arguments are that:

• It promotes encapsulation, because there is less code that needs access to the internals of a class.
• It makes writing function templates easier, because you don't have to guess each time whether some function is a member or not.
• It keeps the class small, which in turn makes it easier to test and maintain.

Although I see the value in these argument, I see a huge drawback: my IDE can't help me find these functions! Whenever I have an object of some kind, and I want to see what operations are available on it, I can't just type "pMysteriousObject->" and get a list of member functions anymore.

Keeping a clean design is in the end about making your programming life easier. But this would actually make mine much harder.

So I'm wondering if it's really worth the trouble. How do you deal with that?

Answer 1

Scott Meyers has a similar opinion to Sutter, see here.

He also clearly states the following:

"Based on his work with various string-like classes, Jack Reeves has observed that some functions just don't "feel" right when made non-members, even if they could be non-friend non-members. The "best" interface for a class can be found only by balancing many competing concerns, of which the degree of encapsulation is but one."

If a function would be something that "just makes sense" to be a member function, make it one. Likewise, if it isn't really part of the main interface, and "just makes sense" to be a non-member, do that.

One note is that with overloaded versions of eg operator==(), the syntax stays the same. So in this case you have no reason not to make it a non-member non-friend floating function declared in the same place as the class, unless it really needs access to private members (in my experience it rarely will). And even then you can define operator!=() a non-member and in terms of operator==().