C++ C++;类的全局变量/实例对象的别名
我有一个头文件和类声明以及一个全局对象实例:C++ C++;类的全局变量/实例对象的别名,c++,C++,我有一个头文件和类声明以及一个全局对象实例: struct ClassName { }; extern ClassName ClassObject; 但在CPP代码中,我希望通过较短的名称访问它,例如CO,而不是ClassObject 理想情况下,我想做一些类似于typedef ClassObject CO但它不受支持 我不想使用#define CO ClassObject,因为这很危险 我不想用 extern ClassName &CO; ClassName &CO=Clas
struct ClassName
{
};
extern ClassName ClassObject;
但在CPP代码中,我希望通过较短的名称访问它,例如CO
,而不是ClassObject
理想情况下,我想做一些类似于typedef ClassObject CO代码>但它不受支持
我不想使用#define CO ClassObject
,因为这很危险
我不想用
extern ClassName &CO;
ClassName &CO=ClassObject;
因为这会降低性能,访问CO
必须首先查找地址值,而ClassObject
则不必这样做。因此,使用ClassObject
将比CO
更快,但我需要相同的性能
与工会一起受审
union
{
ClassName ClassObject;
ClassName CO;
};
但它要求联合是静态的,所以不能在头文件中声明,也不能跨其他CPP文件共享
这是一种很不幸的常见设计弊病,程序员任意地将问题定义得如此狭窄,以至于他们将所有可能的解决方案都排除在外
宏被认为是“危险的”,尽管这个宏实际上没有什么特别危险的地方;它只是一个名称变成了一个不同的名称(从概念上讲,只有两个字母是危险的,但这并不比使用两个字母的标识符更危险)。因此它被忽略了,即使它是可行的解决方案(除了缺少名称空间范围之外,但您几乎肯定对此不感兴趣,因为您希望名称尽可能短)
引用被视为“降低性能”,尽管没有证据表明在这种特殊情况下引用速度缓慢,也没有证据表明您的应用程序的性能受到对全局可访问对象的间接访问的重大影响。因此,它被忽略,即使这是一个完全有效的引用在C++中使用,并且直接类似于别名。
如果你从所有好的解决方案都是坏的这一前提出发,那么很明显,你不会留下任何好的解决方案。这就是你发现自己的地方
但实际上,最好的解决方案是避免为像这样的变量创建微小的别名。为复杂的模板类(如std::vector
等)创建别名是一回事,在这些类中,有大量的粗糙和冗长的内容花费在比表面上简单得多的事情上。缩写一个对象名是另一回事,特别是如果缩写只有两个字母那么短的话
如果两个字母的名称在此上下文中是一个具有充分描述性的名称,那么它应该始终被称为。如果长名称很长,因为它需要那么长才能充分描述,那么这种描述性很可能在任何地方都很重要。不管您如何实现这个别名,在同一个范围内为同一个对象使用两个名称都会让需要阅读此代码并了解其作用的人感到困惑。“某人”很可能就是你未来的自我
所以就。。。不要这样做
标题中只有这个“extern ClassName&CO;”
”。因此,在编译CPP文件时,他们不知道CO
实际指向什么
如果这真的,真的,真的困扰您,C++17提供了内联
变量,这将允许您放置内联ClassName&CO=ClassObject“因为这会降低性能,访问CO必须首先查找地址值,而ClassObject则不必查找。”两个问题:为什么您认为这是真的?也就是说,为什么您认为编译器无法意识到引用总是引用该特定变量,因此不会执行比类对象
所需的更多工作?另外,为什么您认为这个对象的访问时间会影响应用程序的性能?因为只有这个“extern ClassName&CO;”会在头中。因此,在编译CPP文件时,他们不知道CO实际上指的是什么。“还有,为什么你认为这个对象的访问时间对你的应用程序的性能很重要?”——因为我是一个优秀的程序员,能够毫无牺牲地编写高性能代码。这也是一个实时3d游戏引擎。你怎么知道这将是“没有任何牺牲的高性能代码”?ClassObject
是否每次访问时都会出现在处理器的缓存中?难道没有比通过全局变量更有效的方法来访问此类封装的数据吗?或者性能差异可以忽略不计,您应该关注一些重要的事情,比如正确地为引擎线程(这意味着避免全局状态,而不是对其进行微观优化)?“仅此”extern ClassName&CO;“将在标题中”这不是您的示例所做的。而且,您可以始终在函数中本地创建引用,这些函数使用的ClassObject
足够广泛,需要对其进行缩写。