c++ - GNU _M_ 前缀背后的心态

Question

如果我们看一下 GNU 的 libstdc++ 实现，我注意到在标准类的实现中，各种类的private 成员函数都带有前缀 _M_ .例如，std::basic_string<>其中有一个成员叫bool _M_is_shared() const; .

我理解为私有(private)成员变量制定某种命名约定的动机。这有助于从视觉上区分类成员和函数局部变量。但我不明白为什么 _M_私有(private)成员函数首选前缀。

如果我看到一些调用的代码，例如:is_shared();基本上只有几个选项:

1. 是这个类的成员函数
2. 是父类的成员函数
3. 这是一个全局函数。

前两个都有前缀，所以没用。由于 namespace 污染问题，最后一个不会在任何理智的实现中发生。库应该引入的唯一全局变量是标准规定的全局变量。所以这就是问题的症结所在......

因为私有(private)成员函数不可公开访问。不能以任何方式影响派生类。我不认为名称冲突在这里真的是一个问题......基本上这些只不过是一个私有(private)实现细节。为什么要为 (IMO) 丑陋而烦恼 _M_前缀？标准中是否有禁止引入额外私有(private)成员的内容？如果是这样的话，那会让我觉得很愚蠢，除非我遗漏了什么。

Answer 1

以下划线开头然后是大写字母或两个下划线开头的标识符“保留用于在所有上下文中实现”。

这意味着根据标准，某人的程序 #define _M_is_shared false 并破坏库头文件是非法的。如果他们使用更普通的标识符，则在其他有效程序中发生此类名称冲突的风险会更大。