> It’s become part of the “modern C++ dogma” that free functions are part of a<p>> type’s interface, just like public members. But some things that are part of a<p>> type’s interface, you call function-style; others, you call dot-style—and,<p>> because there’s no rhyme or reason behind the distinction, you just have to<p>> memorize which are which. And, when designing types, and protocols for those<p>> types to interact with, you have to pick one arbitrarily, and be careful to be<p>> consistent everywhere.<p>Is this really it though? I don't agree that "there's no rhyme or reason behind the distinction." In fact, it's probably because non-member functions improve encapsulation [1], and because it is not possible to calculate the length of an internal buffer in C++ from outside the class. Unlike in Python, you can't access "private" or implementation specific members in a C++ class, so getting the length of a list or vector is something that has to be part of the class. On the other hand, you can access elements of a class without needing the underlying implementation, so it's reasonable to write a find procedure that is separate from the class itself.<p>For this reason, you're not "pick[ing] one [protocol] arbitrarily," you're doing it to preserve encapsulation and thus have a stronger object orientation. Perhaps the author can shed some light on what they meant here.<p>EDIT: minor formatting of quote<p>[1] <a href="http://www.drdobbs.com/cpp/how-non-member-functions-improve-encapsu/184401197" rel="nofollow">http://www.drdobbs.com/cpp/how-non-member-functions-improve-...</a>