> It’s become part of the “modern C++ dogma” that free functions are part of a > type’s interface, just like public members. But some things that are part of a

> It’s become part of the “modern C++ dogma” that free functions are part of a > type’s interface, just like public members. But some things that are part of a > type’s interface, you call function-style; others, you call dot-style—and, > because there’s no rhyme or reason behind the distinction, you just have to > memorize which are which. And, when designing types, and protocols for those > types to interact with, you have to pick one arbitrarily, and be careful to be > consistent everywhere. 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. 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. EDIT: minor formatting of quote [1] http://www.drdobbs.com/cpp/how-non-member-functions-improve-encapsu/184401197 http://www.drdobbs.com/cpp/how-non-member-functions-improve-...