If we look at the libstdC ++ GNU implementation, I noticed that in the standard class implementations, the private member functions of various classes have a prefix _M_. For example, it std::basic_string<>has, among other things, an element with a name bool _M_is_shared() const;.
I understand the motivation to have some kind of naming convention for private member variables. This helps to visually distinguish between classes and functional local variables. But I do not understand why the prefix _M_is preferred for private member functions.
If I see some code that calls, for example: is_shared();essentially there are only a few options:
- this is a member function of this class
- this is a member function of the parent class
- This is a global feature.
The first two, both will have a prefix so that it does not help. The latter will not be implemented in any reasonable implementation due to problems with namespace pollution. The only globals that a library should introduce are those prescribed by the standard. So, here is the gist of the question ...
Since private member functions are not publicly available. Cannot affect derived classes. I don’t think the name collision is really a concern here ... and basically it is nothing more than a private implementation. Why bother with (IMO) ugly prefix _M_? Is there anything in the standard that prohibits the introduction of additional private members? If so, that will hit me as stupid, if there isn’t something that I don’t see.