Question

通常我不是指实用程序，我的意思是包含多个类型想要使用的枚举的标题等。

例如，如果多个类型可以包含Color，这是一个枚举，那么您可以使其可用。有些人会说它把它“放在最适合的”类中，但是这会产生头依赖性问题。

我真的不喜欢创建包含这样的东西的标题，因为它似乎使代码更复杂。我正在寻找其他人在遇到这样的情况时所采用的技术的想法。如果他们使用“Common”标题等

Answer 1

我总是使用几乎永远不会更改的Common.h文件，并且包含几乎所有文件中极可能需要的定义。我认为它可以提高工作效率，这样您就不必打开另一个.cpp文件并复制您知道自己肯定需要的所有标题的列表。

例如，以下是我的Common.h的两个摘录：

typedef unsigned char uint8;
typedef signed char int8;
typedef unsigned char uint08;
typedef signed char int08;
typedef unsigned short uint16;
typedef signed short int16;
typedef unsigned int uint32;
typedef signed int int32;
typedef unsigned long long uint64;
typedef signed long long int64;
typedef const char cchar;
typedef const bool cbool;
typedef char Byte;

#ifdef ASSERT
/* Re-defining assert */
#undef ASSERT
#endif

#ifdef DEBUG
#ifndef ASSERTIONS
#define ASSERTIONS
#endif
#endif

#define ASSERT_ALWAYS(Expression)   if (!(Expression)) FatalError(ErrorInfo("Assertion Failure", #Expression, FUNCTION_NAME, __FILE__, __LINE__))

#ifdef ASSERTIONS
#ifdef DEBUG
#define ASSERT(Expression)   ASSERT_ALWAYS(Expression)
#else
#define ASSERT(Expression)   if (!(Expression)) ErrorLog("[Release Assertions]: The following assertion failed: " # Expression)
#endif
#else
#define ASSERT(Expression)
#endif

Answer 2

只要只有少数人在您的项目上工作，公共标题就可以了。一旦有20多人编辑该文件并来回合并更改，您就会开始噩梦。

也许另一种方法是拥有color.h或common/color.h文件，这会对您的文件强制执行某些结构。

Answer 3

我个人不是粉丝。

我的意思是当你修改只在一个地方使用的常量（或类型）时，你需要重新编译整个项目。
常数（或类型的定义）的值和所述常数（或类型）的使用在两个不同的地方。

一般来说，我喜欢定义一个只使用一次的常量，在它的使用位置旁边。这意味着如果我想知道常量的值，那么我就可以看一下。这也意味着我只需要在所述常量变化时重新编译一个文件。

如果广泛使用常量或类型，或者模块之间共享常量或类型，则存在常量头文件的情况。

Answer 4

IMO Common标题是很好的做法如果你将它们限制为包含很少改变的东西

typedef unsigned int UINT32;

如果你发现自己编辑了很多这个文件，那么你的内容就不属于那里了。

Answer 5

我更喜欢明确每个cpp文件需要什么。从长远来看，我发现它更容易，它可以防止“常见”标题导致文件在不需要时重建。随着项目的发展，严格“仅包含您需要的”策略可以帮助缩短构建时间。当你最初建立一个新课时，这个价格有点过分。我经常只有一个enum或typedef的头文件，我甚至可以使用一个特殊的构建配置来构建没有预编译的头文件（因为我使用Visual Studio）使用#pragma hdrstop来定义我的预编译头文件而不是比让每个文件都需要包含一个用于此目的的公共文件。

多年来，我发现这可以很好地保持构建时间，并允许代码移动（进入库或跨越其他项目）或构建用于测试工具。

我认为常见的标题是不必要的耦合，应该被删除，说实话，这是一种懒惰和缺乏对细节的关注的标志。

Answer 6

如果你想要'全局'枚举，那么将它们放在自己的命名空间中，而不是污染全局命名空间，例如：

// Types.h

namespace MyTypes
{
    enum Color
    {
        RED,
        BLUE,
        GREEN,
    };
}

就我个人而言，我更喜欢保持与类相关的枚举，但YMMV。

具有“共同”标题的实践

6 个答案: