首先,我是c ++的新手,并且'尝试'为我的变量添加前缀。 但我不是很清楚。 所以我的问题是,用“g_”为静态变量加前缀是否正确? 谢谢!
using namespace std;
// The main window class name.
static TCHAR g_szWindowClass[] = _T("win32app");
// The string that appears in the application's title bar.
static TCHAR g_szTitle[] = _T("Win32 App");
...
答案 0 :(得分:1)
最好使用前缀而不是区分全局变量的前缀。但
最好尽可能避免全局变量,
而不是C样式前缀,在C ++中,您可以使用命名的命名空间。
它还有很多优点可以避免微软的T
宏观愚蠢。它支持Windows 9x,您可能不会定位Windows 9x。此外,它有许多优点,尤其是维护,以避免微软愚蠢的匈牙利表示法,即sz
之类的前缀,它支持微软1980年代的 Programmers Workbench 帮助系统,就像Windows 98不再那么相关。
此外,在可能的情况下使用const
可能是有利的。
请注意,命名空间级别的const
表示静态存储类,因此不再需要显式static
。
因此,而不是当前的
// The main window class name.
static TCHAR g_szWindowClass[] = _T("win32app");
DO
namespace g {
auto const windowClassName = L"win32app";
}
与
C ++名称空间g
而不是C前缀g_
,
const
,保证不修改此变量,
直接使用宽字符文字而不是Microsoft Windows 9x T
宏。
然后,您可以在g::windowClassName
之后引用using namespace g;
或不带前缀,或者使用g
的别名。
我用于命名空间的特定括号约定是支持嵌套命名空间而没有缩进麻烦。不幸的是,普通编辑不支持。
答案 1 :(得分:1)
C ++没有正式的命名约定。它确实有一些规则用于变量名称或一般的标识,你必须遵循,但除此之外,名称完全取决于你,它带来了所有的灵活性和危险(很多)像其他语言一样。)
以下是规则的完整概述:http://en.cppreference.com/w/cpp/keyword
因此,例如,_G_szTitle
会出错,但g_szTitle
没问题。
真正的问题是你几乎肯定不想使用全局变量。全局变量几乎总是糟糕的设计。避免它们。
另一个较小的问题是你使用所谓的"匈牙利符号"。谷歌有点了解为什么许多人(包括我自己)反对它,特别是在像C ++这样的语言中。
答案 2 :(得分:0)
C ++ 11 Standard(draft n3337):
17.6.4.3.2全局名称[global.names]
某些名称和功能签名集始终保留给实现:
- 每个包含双下划线__的名称或以下划线后跟大写字母(2.12)开头的名称都保留给实现以供任何使用。
- 以下划线开头的每个名称都保留给实现,以用作全局命名空间中的名称。
除了这些之外,您对全局变量选择的(标识符)名称没有任何限制。
某些人使用的约定是g_
为全局变量加前缀,成员变量加m_
等等。这是一个选择问题;语言本身并没有强加这样的要求。因此,只要标识符以英文字母开头,您就可以自由地为它们命名并为它们添加前缀。
至于全局变量的使用,我想说如果你刚刚开始学习C ++,使用它们,受到伤害然后意识到它们是坏的;你会明白为什么他们总是受到有经验的程序员的谴责。只是告诉他们不好会增加一些价值,有些事情可以通过经验更好地学习。
答案 3 :(得分:0)
全局变量最明显的定义是在命名空间范围内声明的变量(包括最外面的命名空间)。
现在,你可以争辩说在命名空间范围内声明的变量也被声明为static
,因此在给定的转换单元之外是不可见的。同样,在未命名的命名空间中声明的变量可能被视为非全局变量。但是,这两种变量都共享了全局变量的许多不良属性。例如,它们在从多个线程访问时引入了序列化点。
因此,我认为实际上更广泛的变量是全局变量,即类和函数区域static
变量中的static
数据成员。这些中的每一个在整个程序中也只存在一次。仅仅因为这些构造碰巧被用于某些[反]设计模式(值得注意的单身人士)并不会神奇地祝福全局变量!
关于为变量名添加前缀: not 在变量名中包含类型前缀!在C ++中,编译器已经充分检查了类型。包括类型往往导致最终错误的名称。特别是关于全局变量,这里是我对它们的前缀的建议:无论何时你想使用全局变量的前缀停止你正在做什么!您正在构建问题,而您应该尝试更改设计以消除对全局变量的需求!