我应该使用＃define，enum还是const？

在我正在研究的C ++项目中，我有一个标志类型的值，可以有四个值。这四个标志可以组合。标志描述数据库中的记录，可以是：

• 新纪录
• 删除记录
• 修改记录
• 现有记录

现在，对于每条记录，我希望保留此属性，因此可以使用一个枚举：

enum { xNew, xDeleted, xModified, xExisting }

但是，在代码的其他位置，我需要选择对用户可见的记录，因此我希望能够将其作为单个参数传递，例如：

showRecords(xNew | xDeleted);

因此，似乎我有三种可能的解决方法：

#define X_NEW      0x01
#define X_DELETED  0x02
#define X_MODIFIED 0x04
#define X_EXISTING 0x08

要么

typedef enum { xNew = 1, xDeleted, xModified = 4, xExisting = 8 } RecordType;

要么

namespace RecordType {
    static const uint8 xNew = 1;
    static const uint8 xDeleted = 2;
    static const uint8 xModified = 4;
    static const uint8 xExisting = 8;
}

空间要求很重要（字节vs int），但并不重要。使用define会丢失类型安全性，并且enum会丢失一些空间（整数），并且在我想进行按位运算时可能不得不强制转换。随着const我想我也失去了类型安全，因为随机的uint8可能错误地进入。

还有其他更清洁的方法吗？

如果没有，您将使用什么，为什么？

PS其余代码是没有#defines的现代C ++ ，并且我在很少的空间中使用了名称空间和模板，因此它们也不是没有问题。

组合策略以减少单一方法的弊端。我在嵌入式系统中工作，因此以下解决方案基于以下事实：整数和按位运算符速度快，内存少且闪存使用率低。

将枚举放在名称空间中，以防止常量污染全局名称空间。

namespace RecordType {

一个枚举声明并定义一个已检查类型的编译时间。始终使用编译时类型检查来确保为参数和变量指定了正确的类型。在C ++中不需要typedef。

enum TRecordType { xNew = 1, xDeleted = 2, xModified = 4, xExisting = 8,

创建另一个成员的无效状态。这可以用作错误代码。例如，当您想返回状态但I / O操作失败时。这对于调试也很有用；在初始化列表和析构函数中使用它可以知道是否应使用变量的值。

xInvalid = 16 };

考虑到此类型有两个用途。跟踪记录的当前状态并创建掩码以选择处于某些状态的记录。创建一个内联函数以测试该类型的值是否对您的目的有效；作为状态标记与状态掩码。这将捕获错误，因为typedef只是一个int和值，例如0xDEADBEEF通过未初始化或错误指向的变量可能存在于您的变量中。

inline bool IsValidState( TRecordType v) {
    switch(v) { case xNew: case xDeleted: case xModified: case xExisting: return true; }
    return false;
}

 inline bool IsValidMask( TRecordType v) {
    return v >= xNew  && v < xInvalid ;
}

using如果要经常使用该类型，请添加指令。

using RecordType ::TRecordType ;

值检查功能在断言中很有用，可在使用后立即捕获不良值。运行时发现错误的速度越快，其可能造成的损害就越小。

这里有一些例子将它们放在一起。

void showRecords(TRecordType mask) {
    assert(RecordType::IsValidMask(mask));
    // do stuff;
}

void wombleRecord(TRecord rec, TRecordType state) {
    assert(RecordType::IsValidState(state));
    if (RecordType ::xNew) {
    // ...
} in runtime

TRecordType updateRecord(TRecord rec, TRecordType newstate) {
    assert(RecordType::IsValidState(newstate));
    //...
    if (! access_was_successful) return RecordType ::xInvalid;
    return newstate;
}

确保正确的值安全性的唯一方法是使用带有运算符重载的专用类，该类留给其他读者练习。

忘记定义

他们会污染您的代码。

位域？

struct RecordFlag {
    unsigned isnew:1, isdeleted:1, ismodified:1, isexisting:1;
};

永远不要使用它。您更关心速度，而不是节省4个整数。使用位域实际上比访问任何其他类型慢。

但是，结构中的位成员具有实际缺陷。首先，内存中的位顺序因编译器而异。此外，许多流行的编译器会生成用于读写位成员的低效率代码，并且由于大多数机器无法操纵内存中的任意位集，因此存在与位字段相关的潜在严重线程安全问题（尤其是在多处理器系统上），但必须加载并存储整个单词。例如，尽管使用了互斥锁，但以下内容仍不是线程安全的

资料来源：http : //en.wikipedia.org/wiki/Bit_field：

如果你需要更多的理由不使用位域，或许雷蒙德陈会说服你在他的旧事新帖子：位域的成本效益分析为布尔值的集合在http://blogs.msdn.com/oldnewthing/存档/2008/11/26/9143050.aspx

const int？

namespace RecordType {
    static const uint8 xNew = 1;
    static const uint8 xDeleted = 2;
    static const uint8 xModified = 4;
    static const uint8 xExisting = 8;
}

将它们放在命名空间中很酷。如果在您的CPP或头文件中声明了它们，则它们的值将被内联。您将可以使用这些值上的开关，但是会稍微增加耦合。

嗯，是的：删除static关键字。照常使用C ++时不推荐使用static，并且如果uint8是内建类型，则无需使用它就可以在同一模块的多个源包含的标头中对此进行声明。最后，代码应为：

namespace RecordType {
    const uint8 xNew = 1;
    const uint8 xDeleted = 2;
    const uint8 xModified = 4;
    const uint8 xExisting = 8;
}

这种方法的问题是您的代码知道常量的值，这会稍微增加耦合。

枚举

与const int相同，但键入强度更高。

typedef enum { xNew = 1, xDeleted, xModified = 4, xExisting = 8 } RecordType;

但是，它们仍在污染全局名称空间。顺便说一下... 删除typedef。您正在使用C ++。那些枚举和结构的typedef对代码的污染比其他任何事情都多。

结果有点：

enum RecordType { xNew = 1, xDeleted, xModified = 4, xExisting = 8 } ;

void doSomething(RecordType p_eMyEnum)
{
   if(p_eMyEnum == xNew)
   {
       // etc.
   }
}

如您所见，您的枚举正在污染全局名称空间。如果将此枚举放在名称空间中，则将具有以下内容：

namespace RecordType {
   enum Value { xNew = 1, xDeleted, xModified = 4, xExisting = 8 } ;
}

void doSomething(RecordType::Value p_eMyEnum)
{
   if(p_eMyEnum == RecordType::xNew)
   {
       // etc.
   }
}

extern const int吗？

如果要减少耦合（即能够隐藏常量的值，因此可以根据需要修改它们而无需完全重新编译），则可以将int声明为标头中的extern，并将其声明为CPP文件中的常量，如以下示例所示：

// Header.hpp
namespace RecordType {
    extern const uint8 xNew ;
    extern const uint8 xDeleted ;
    extern const uint8 xModified ;
    extern const uint8 xExisting ;
}

和：

// Source.hpp
namespace RecordType {
    const uint8 xNew = 1;
    const uint8 xDeleted = 2;
    const uint8 xModified = 4;
    const uint8 xExisting = 8;
}

但是，您将无法在这些常量上使用switch。所以最后选择毒药... :-p

您是否排除了std :: bitset？标志集就是它的用途。做

typedef std::bitset<4> RecordType;

然后

static const RecordType xNew(1);
static const RecordType xDeleted(2);
static const RecordType xModified(4);
static const RecordType xExisting(8);

由于位集有很多运算符重载，因此您现在可以

RecordType rt = whatever;      // unsigned long or RecordType expression
rt |= xNew;                    // set 
rt &= ~xDeleted;               // clear 
if ((rt & xModified) != 0) ... // test

或与之非常相似的东西-由于我还没有测试过，请多多指教。您也可以按索引引用位，但是通常最好只定义一组常量，而RecordType常量可能更有用。

假设您已经排除了问题，那么我投票支持该枚举。

我不认为强制转换枚举是一个严重的缺点-好吧，这有点嘈杂，并且为枚举分配超出范围的值是未定义的行为，因此从理论上讲，可以使用一些不寻常的C ++射击自己实现。但是，如果仅在必要时执行此操作（即从int到枚举iirc进行转换），那么这就是人们以前见过的完全正常的代码。

我也怀疑枚举的空间成本。uint8变量和参数可能不会使用比int少的堆栈，因此仅存储类中的内容很重要。在某些情况下，将多个字节打包到一个结构中会获胜（在这种情况下，您可以将枚举转换为uint8存储空间），但通常情况下，填充会无济于事。

因此，与其他枚举相比，该枚举没有任何缺点，并且优点是给您带来了一些类型安全性（没有显式强制转换就不能分配一些随机整数值）和引用所有内容的简洁方法。

顺便说一句，我也希望在枚举中放入“ = 2”。这不是必需的，但是“最少惊讶的原则”建议所有4个定义看起来都应该相同。

以下是有关const，宏和枚举的几篇文章：

符号常量
枚举常量与常量对象

我认为您应该避免使用宏，尤其是因为您编写的大多数新代码都是使用现代C ++编写的。

如果可能，请勿使用宏。当涉及到现代C ++时，他们并不是很欣赏。

枚举会更合适，因为它们提供了“标识符的含义”以及类型安全性。您可以清楚地知道“ xDeleted”是“ RecordType”，并且代表“记录类型”（哇！）。Consts为此需要注释，也需要在代码中上下移动。

随着定义我失去类型安全

不必要...

// signed defines
#define X_NEW      0x01u
#define X_NEW      (unsigned(0x01))  // if you find this more readable...

和枚举我失去了一些空间（整数）

不一定-但是在存储点上您必须明确...

struct X
{
    RecordType recordType : 4;  // use exactly 4 bits...
    RecordType recordType2 : 4;  // use another 4 bits, typically in the same byte
    // of course, the overall record size may still be padded...
};

当我想进行按位运算时，可能必须进行转换。

您可以创建运算符来消除这种麻烦：

RecordType operator|(RecordType lhs, RecordType rhs)
{
    return RecordType((unsigned)lhs | (unsigned)rhs);
}

使用const我想我也会失去类型安全性，因为随机的uint8可能会错误地进入。

这些机制中的任何一种都可能发生相同的情况：范围和值检查通常与类型安全正交（尽管用户定义的类型（即您自己的类）可以对其数据实施“不变式”）。使用枚举时，编译器可以自由选择更大的类型来承载值，并且未初始化，损坏或设置错误的枚举变量仍可能最终将其位模式解释为您不希望的数字-比较不等于枚举标识符，它们的任意组合以及0。

还有其他更清洁的方法吗？/如果没有，您将使用什么，为什么？

好吧，最后，一旦图片中有位字段和自定义运算符，枚举的可靠的C样式按位或运算就可以很好地工作。您可以使用mat_geek的答案中的一些自定义验证功能和断言来进一步提高鲁棒性。通常同样适用于处理字符串，整数，双精度值等的技术。

您可能会争辩说这是“更干净”的：

enum RecordType { New, Deleted, Modified, Existing };

showRecords([](RecordType r) { return r == New || r == Deleted; });

我无动于衷：数据位打包得更紧了，但是代码却显着增长了……取决于您拥有多少个对象，lamdbas（虽然很漂亮）仍然比按位OR更加混乱和难以正确处理。

顺便说一句，关于线程安全性相当薄弱的恕我直言的论点-最好记住是作为背景考虑，而不是成为主导的决策驱动力；即使不知道它们的打包情况，也更可能在位域上共享一个互斥锁（互斥锁是相对庞大的数据成员-我必须非常担心性能，考虑在一个对象的成员上使用多个互斥锁，并且我会仔细查看）足以注意到它们是位字段）。任何子字长类型都可能有相同的问题（例如uint8_t）。无论如何，如果您迫切希望获得更高的并发性，则可以尝试原子比较和交换样式的操作。

即使您必须使用4个字节来存储枚举（我对C ++并不熟悉-我知道您可以在C＃中指定基础类型），还是值得的-使用枚举。

在具有GB内存的服务器的当今时代，通常在应用程序级别上，像4字节vs. 1字节的内存之类的事情并不重要。当然，如果在您的特定情况下，内存使用非常重要（并且您无法让C ++使用字节来支持枚举），则可以考虑使用“静态const”路由。

归根结底，您必须问自己，是否值得为数据结构使用3个字节的内存节省而使用“静态常量”来维护？

还有其他需要注意的地方-IIRC，在x86上，数据结构是4字节对齐的，因此，除非在“记录”结构中有许多字节宽度的元素，否则实际上并不重要。在权衡性能/空间的可维护性之前，请进行测试并确保能做到。

如果您想要类的类型安全性，并且方便使用枚举语法和位检查，请考虑使用C ++中的“安全标签”。我和作者一起工作过，他很聪明。

不过要当心。最后，该程序包使用模板和宏！

您实际上是否需要将标志值作为概念整体传递，还是要有很多每个标志的代码？无论哪种方式，我都认为将其作为1位位域的类或结构可能更清晰：

struct RecordFlag {
    unsigned isnew:1, isdeleted:1, ismodified:1, isexisting:1;
};

然后，您的记录类可以具有struct RecordFlag成员变量，函数可以采用struct RecordFlag类型的参数，等等。编译器应将位字段打包在一起，以节省空间。

对于可能将值组合在一起的事情，我可能不会使用枚举，更典型的是枚举是互斥状态。

但是，无论使用哪种方法，为了更清楚地表明这些值是可以组合在一起的位，请对实际值使用以下语法：

#define X_NEW      (1 << 0)
#define X_DELETED  (1 << 1)
#define X_MODIFIED (1 << 2)
#define X_EXISTING (1 << 3)

使用左移可以帮助表明每个值都打算是一个单一的位，以后某人执行诸如添加新值并为其分配值为9的错误的可能性较小。

基于 KISS，高内聚和低耦合，提出以下问题-

• 谁需要知道？我的班级，我的图书馆，其他班级，其他图书馆，第三方
• 我需要提供什么级别的抽象？消费者是否了解位操作。
• 我必须从VB / C＃等接口吗？

有一本很棒的书《大规模C ++软件设计》，它在外部提升了基本类型，如果您可以避免其他头文件/接口的依赖性，您应该尝试这样做。

如果您使用的是Qt，则应该看看QFlags。QFlags类提供了一种类型安全的方式来存储枚举值的OR组合。

我宁愿去

typedef enum { xNew = 1, xDeleted, xModified = 4, xExisting = 8 } RecordType;

仅仅是因为：

1. 它更干净，并使代码可读性和可维护性。
2. 它在逻辑上将常量分组。
3. 程序员的时间更为重要，除非您的工作是保存这3个字节。

我并不是想过度设计所有东西，但是有时候在这些情况下，值得创建一个（小）类来封装此信息。如果创建一个RecordType类，则它可能具有以下功能：

void setDeleted（）;

void clearDeleted（）;

bool isDeleted（）;

等等...（或任何适合的常规）

它可以验证组合（在并非所有组合都是合法的情况下，例如，如果不能同时设置“新”和“已删除”）。如果只使用了位掩码等，则设置状态的代码需要验证，一个类也可以封装该逻辑。

该类还可以使您能够将有意义的日志记录信息附加到每个状态，可以添加一个函数以返回当前状态的字符串表示形式（或使用流操作符“ <<”）。

对于所有担心存储的问题，您仍然可以让该类仅具有一个'char'数据成员，因此仅占用少量存储（假设它是非虚拟的）。当然，取决于硬件等，您可能会遇到对齐问题。

如果“位”的其余部分位于cpp文件而不是头文件中的匿名命名空间中，则可能无法让“世界”的其余部分看到实际的位值。

如果您发现使用enum /＃define / bitmask等的代码具有大量用于处理无效组合，日志记录等的“支持”代码，那么封装在类中可能值得考虑。当然，大多数情况下，简单的问题可以通过简单的解决方案来解决。