> Or more simply, why not make it a member method to begin with? You may not be the author/maintainer of that class. > Why not just make your Extension an oth

> Or more simply, why not make it a member method to begin with? You may not be the author/maintainer of that class. > Why not just make your Extension an other class that would be inherited? Because now I have a down casting issue (especially when talking about non-heap "objects"). Which means implementing and forwarding dozens of methods, and/or sloppy bug-prone (when some other developer puts variables on the class without noticing) implicit casts. > I wish the article included some real-world practical example of when that would be useful The classic one is interface helpers. Methods which smooth out the usage of an interface but are not relevant to the implementation of it. Yes one can put those methods on the interface's definition. But this allows separating where the interface is declared (some header some where) and where the code for it is defined (some code file), potentially across libraries (e.g. a header only "library" of interfaces, and a utility library of methods for making it nice to use). Notably this also avoids some frustrating header shenanigans and allows writing interface helpers against concrete types to come up with a more natural library organization. The next one is it much easier to write "literate programming" style code in C++ (which is nice because they often make types "disappear" in their usage, and many argue provide more readable code as a consequence). A problem many developers currently solve with operator overload (see `<<` for the C++ standard printing library). This also makes it way way easier for such literate programming to be extensible (believe me I wrote the templates for extensible literate programming once, it's insanely painful). Also, depending on how these implement templates, they might be a much more appreciated method of adding optional class methods to templates by making the method a compile error to call in the first place ("missing method") rather than a substitution failure error ("<massive call stack>").