Mentality behind GNU _M_ prefixing

Question

If we take a look at GNU's implementation of libstdc++, I've noticed that in the implementations of the standard classes that private member functions of various classes are prefixed with _M_. For example, std::basic_string<> has among others a member called bool _M_is_shared() const;.

I understand the motivation to have some sort of naming convention for private member variables. This helps is distinguishing between class members and function local variables visually. But I don't get why the _M_ prefix is preferred for private member functions.

If I see some code that called for example: is_shared(); there is essentially only a few options:

1. it's a member function of this class
2. it's a member function of a parent class
3. it's a global function.

The first two, would both have the prefix so it's no help. The last one wont happen in any sane implementation because of namespace pollution concerns. The only globals the library should introduce are ones prescribed by the standard. So here's the crux of the question...

Since private member functions aren't publicly accessible. Can't effect derived classes in any way. I don't think that name collisions are really a concern here... and basically these are nothing more than a private implementation detail. Why bother with the (IMO) ugly _M_ prefixing? Is there something in the standard that disallows introducing extra private members? If so that would strike me as silly unless there is something I am missing.

Answer 1

Identifiers beginning with an underscore and then a capital letter, or beginning with two underscores, are "reserved for the implementation in all contexts".

This means it would be illegal according to the Standard for someone's program to #define _M_is_shared false and break the library header file. If they used more ordinary identifiers, there would be greater risk of such a name collision in otherwise valid programs.

Answer 2

The standard specifies that names starting with double underscores, or an underscore followed by a capital letter, are reserved for internal compiler or library symbols.

You pointed out that these private symbols won't be accessible, but don't forget about macros and defines. Basically, the idea is as simple as "Let's replace m_member with _M_member".

The relevant part of the standard is 17.4.3.1.2 Global names

Each name the contains a double underscore __ or begins with an underscore followed by an uppercase letter is reserved to the implementation for any use.