Effective C++ Item 23 Prefer non-member non-friend functions to member functions

Question

While puzzling with some facts on class design, specifically whether the functions should be members or not, I looked into Effective c++ and found Item 23, namely, Prefer no

Answer 1

So, first question, should not they be members than?

No, this doesn't follow. In idiomatic C++ class design (at least, in the idioms used in Effective C++), non-member non-friend functions extend the class interface. They can be considered part of the public API for the class, despite the fact that they don't need and don't have private access to the class. If this design is "not OOP" by some definition of OOP then, OK, idiomatic C++ is not OOP by that definition.

stretch the same reasoning to some other functions in vector class

That's true, there are some member functions of standard containers that could have been free functions. For example vector::push_back is defined in terms of insert, and certainly could be implemented without private access to the class. In that case, though, push_back is part of an abstract concept, the BackInsertionSequence, that vector implements. Such generic concepts cut across the design of particular classes, so if you're designing or implementing your own generic concepts that might influence where you put functions.

Certainly there are parts of the standard that arguably should have been different, for example std::string has way too many member functions. But what's done is done, and these classes were designed before people really settled down into what we now might call modern C++ style. The class works either way, so there's only so much practical benefit you can ever get from worrying about the difference.