我有一些相关的方法,所有这些方法都使用一些全局数据(*),并且所有这些方法都将在头文件中实现。我应该......
这两个选项对我来说似乎有点难看,但我想知道其中一个是否有我缺少的有条不紊的好处,这应该让我更喜欢它。我可以尝试向后弯曲并将互斥锁移动到.cpp文件中,这样可能是第三种选择,但它不会很漂亮......
(*) - 在我的具体情况下,它是一个互斥锁。
答案 0 :(得分:0)
从一般的“良好实践”的角度来看,我会避免任何全局数据,并尽可能少地使用静态数据(避免单身综合症)。
第一个问题是:拥有这些物品的几个副本是否有害?通常,如果您不管理硬件访问或类似操作,则不会。即使你应该只使用一个,最好尽量使它尽可能通用,并允许几个类的实例。
此外,静态/全局变量往往会带来线程/进程的问题,因为有时很难计算出您拥有的静态对象的副本数量。
简而言之:将它们放在一个非静态的类中,并将这些“全局”数据放入类中。
如果产生这些数据的原因是由于多个线程或进程,那么从设计的角度来看可能是错误的。
如果您没有选择更合适的解决方案,那么我将使用命名空间:使用全局参数的类将破坏任何程序员对您的代码所期望的封装原则。
编辑:
在问题编辑之后,试图更接近问题:
假设您需要围绕互斥锁的包装器,每个进程都是唯一的。
class MyMutexWrapper // very minimal class, you should finish it.
{
MyMutex mutex;
public:
anyFunction();
};
完成此操作后,您可以创建一个全局实例并通过整个代码共享它。一个更好的解决方案仍然是在任何范围内创建它并将其传递给任何使用它的组件。 例如,您可以传递参考。
这种方法看起来可能更复杂,但它可以避免交叉依赖,并使您的代码结构更清晰=>然后你可以重复使用它,扩展它,维护它......
答案 1 :(得分:0)
在这里使用类的唯一额外好处是,如果有人使用该互斥锁,编译器可以抱怨(当然,如果你将其设为私有)。
但是,在这两种情况下,您只能在标题中声明数据,并且您仍然必须在某些翻译单元中仅定义一次。我建议您省去 in-header 实现,并在同一个翻译单元中隐藏静态互斥锁和函数实现。
从那时起,您可以使用命名空间,因为它只是一个组织问题。