But to follow the line of Bjarne's advice (I've also heard same from Stepanov): One should prefer non-member functions. i.e. there must be some real reason for some function to become a member of a class.
http://www.drdobbs.com/cpp/how-non-member-functions-improve-...
With non member functions declared in the header and defined in a .C file, and suddenly you don't have RIAA any more or exceptions. Your .C files end up being your division of concerns, not classes.
The only time you end up using any C++ features is interacting with a library that prefers member functions.
In fact all code should be in a database, not a file, so changes can be tracked and attributed properly. So a tool can distinguish between 'lines being edited' and 'one function deleted and another added'. And so on.
So what organizing principle is left, since files are largely invisible during the coding process? Well, classes spring to mind.
There will be very few classes in your project if you decide to prefer non member non friend functions as suggested here.
The question being, whether you go along with that suggestion or not?
To make it clear: I favor factoring APIs into classes.
It's strange that C++ luminaries like Stepanov, Meyers and Stroustrup favour non member functions.
But, for instance, `sort` is a good candidate to have outside of a class - and it actually is a global function - std::sort.
When you start preferring non member functions, you tend allocate on the stack.
There are rare items that require heap allocation and other resources. For those you can have classes. What I am saying is that when you prefer non member functions you end up with very few classes.
there's many ways to implement private data. if you prefer non member functions, a class is a bunch of extra keystrokes to achieve the same as the old fashioned C private data.
if you prefer non member functions to member functions, your private data becomes a global variable or struct in a file, and the private data is not accessible by getter/setter functions that are externalised.
Unless you're a fan of `friend` keyword ;)
however, it requires less keystrokes to implement private data in C, than it does to create a class to store private data.
therefore it's questionable, if you are preferring non member non friend functions, whether you should use classes when you want private data.
i refute the idea that private data is a reason to use classes, if you are preferring non member non friend functions as advocated by Stroustrup, Meyers and Stepanov.
as i said already
> There's very little reason for class members unless you want inheritance or polymorphism.
Bjarne has wanted multi-methods for decades.