2

I have been listening to Klaus Iglberger speech on CppCon 2017 called "Free Your Functions" (you can find it on Youtube here: https://www.youtube.com/watch?v=WLDT1lDOsb4) which exposes better the rationale behind a concept coming from the Effective C++ book guideline: "Prefer non-member non-friend functions to member functions".

Looking at all the advantages and disavantages, there is one disavantage that is puzzling me very badly, which is: you do not call those functions using the operator., and they are free to be defined anywhere.

Reading this article about The Interface Principle, which talks extensively about what should to be considered a class public interface (http://www.gotw.ca/publications/mill02.htm), its pretty much clear to me that those free functions are part of the class interface, even if it happens that they can be defined in any file anywhere in the project.

Why is it a disadvantage? Because in my experience, scattering the code around in big projects will cause code duplication, as developers have no way to be aware that some utility function has already been implemented for that class, and they will code it again. And that is something that does not happen when you use operator. to call a function on an object, not only because member function are forced by the language itself to be declared in the same file where the class is declared, but also simply because IDEs usually pop-up a list of the already available member functions as you press the ".".

So the question is: assuming The Interface Principle to be right, and assuming the free function approach to be a good coding guideline, in order to get rid of the disadvantage of people not finding already written free functions for a class, would it be technically possible for IDEs to help developers showing the whole class public interface and not only the class members? Or would it be computational overwhelming or even unrealizable in practice?

nyarlathotep108
  • 5,275
  • 2
  • 26
  • 64
  • 2
    I think you are missing the second criterion for what being part of the interface is `(b) are "supplied with" X` - so they won't be "scattered around" the project. If I write a function `void f(std::string s);` you would not (I hope) think of it as part of the interface of `std::string`. –  May 24 '18 at 13:15
  • @NeilButterworth according to The Interface Principle here described (http://www.gotw.ca/publications/mill02.htm) in the case you function would have been `void f(const std::string& s)` it would have been part of the public interface of `std::string`, as having the this pointer as an implicit parameter or having it explicitly written in a function signature makes from little to no difference at all. I am not sure by the way of your specific case, in which the string is actually copied, but I guess it is. – nyarlathotep108 May 24 '18 at 13:33
  • A class member isn't necessarily "bundled" with the class - all that's needed is visibility of the class definition. To, possibly, answer your question though: `a.m()` positively indicates that `m()` is part of the specified interface of `a` and works as the designer of `a` (or its class) intended - defining a member function requires some "under the hood" understanding of the class, and someone has to be (ahem) braver to try to implement member functions without that understanding. With the syntax `f(a)`, there is less certainty that `f()` is part of the interface – Peter May 24 '18 at 14:10
  • @nyar You are misunderstanding the article, and there is no pointer there - that's a reference. –  May 24 '18 at 14:14
  • @Peter the question is not about if the article is right or wrong in stating the `f(a)` is part of the class public interface. I am assuming the article to be right, as it enforces the free function philosophy in many ways. I am rewording the question in order to make it more technical: would it be possible for an IDE to suggest to the developer the whole class public interface the way it is defined by the Interface Principle? – nyarlathotep108 May 24 '18 at 15:18

0 Answers0