使用名称空间和本地名称

2018-06-10 08:45:31

现在，我的游戏引擎中的模块被组织为名称空间。他们有Open（）和Close（）函数，这些函数的作用类似于类的构造函数和析构函数，并在游戏进入时被调用。

这些模块的例子有：物理管理器，实体管理器，I / O处理器，渲染管理器。

现在，我开始认为将模块的所有变量“撒谎”并通过链接器全局出口是不好的。

将名称空间中的模块重构为类会带来以下开销：

必须有一个全局控制器，允许不同模块之间的交互，通过证明对其实例的访问

模块之间的交互会产生额外的函数调用开销和1-2个指针取消引用

并具有以下优点：

RAII符合

所有状态都可以打包成一个包含模块实例的CState类

适合确保资源被正确删除和分配

我的问题：

我应该考虑将我的引擎模块从命名空间重构到托管类吗？为什么不）？

如果您有一组函数（方法）对一组对象集合进行操作，该对象集合对于该集合之外的其他函数不应该可见，那么将该集合的函数和对象放入一个类中似乎很自然。

必须有一个全局控制器，允许不同模块之间的交互，通过证明对其实例的访问

是否必须有全球控制器？这听起来很像“上帝对象”反模式。即使您通常只有一个类的单个实例，但只要需要访问其他类的各个类中的函数都有一种获取方法，那么它们并不一定都是总体控制器类的成员该访问。

模块之间的交互会产生额外的函数调用开销和1-2个指针取消引用

我不知道你是如何解决这个问题的。我不认为这是事实，但我会建议您先设计清晰度，并且只在性能不足时进行优化。

如果涉及到状态，那么创建一个类以便可以有多个状态实例是很好的。

但是，还有其他的优点和缺点：

命名空间已打开，类已关闭。您可以更轻松地将东西添加到名称空间。

您可以更轻松地在名称空间中创建声明。你不能在类中进行前向声明 - 整个类的声明必须是可见的。

这意味着命名空间可以更容易地完成PIMPL的道德等价物。您只需向前声明您需要的功能即可。有了课程，你需要真正建立一个PIMPL - 这很乏味。

我想认为命名空间只是一个没有数据的类，或者只包含类静态数据的类。也就是说，命名空间就像一个你不能拥有对象的类。但是，不幸的是，C ++的许多限制都阻止了它的真实性。

有时候我最终会得到一个命名空间和一个类。

链接地址: http://www.djcxy.com/p/30685.html