静态const vs #define

使用static constvars比使用#define预处理器更好吗？还是取决于上下文？

每种方法的优点/缺点是什么？

就我个人而言，我讨厌预处理器，因此我总是选择与一起使用const。

a的主要优点#define是它不需要内存来存储在程序中，因为它实际上只是用文字值替换了一些文本。它还具有没有类型的优点，因此可以将其用于任何整数值而不会生成警告。

“ const”的优点是可以确定范围，并且可以在需要传递指向对象的指针的情况下使用它们。

不过，我不知道您对“ static”部分的理解是什么。如果您要全局声明，则将其放在匿名名称空间中，而不要使用static。例如

namespace {
   unsigned const seconds_per_minute = 60;
};

int main (int argc; char *argv[]) {
...
}

#defines，consts和（您忘记了）enums 之间的优缺点，具体取决于用法：

1. enums：

   • 仅适用于整数值
   • 正确确定范围/标识符冲突问题可以很好地处理，尤其是在C ++ 11枚举类中，其中的枚举enum class X被范围消除了歧义X::
   • 强类型，但具有足够大的有符号或无符号int大小，您无法在C ++ 03中对其进行控制（尽管您可以指定一个位字段，如果枚举是struct /的成员，则应将它们打包到其中类/联合），而C ++ 11默认为，int但可以由程序员明确设置
   • 无法使用地址-没有一个地址，因为枚举值已在使用时被有效地内联替换
   • 较强的使用约束（例如，递增- template <typename T> void f(T t) { cout << ++t; }将不会编译，尽管您可以使用隐式构造函数，强制转换运算符和用户定义的运算符将枚举包装到类中）
   • 每个常量的类型都从封闭的枚举中template <typename T> void f(T)获取，因此，当从不同的枚举中传递相同的数值时，它们将获得不同的实例化，而所有枚举都与任何实际f(int)实例化都不同。每个函数的目标代码可能是相同的（忽略地址偏移量），但是我不希望编译器/链接器消除不必要的副本，尽管您可以在需要时检查编译器/链接器。
   • 即使使用typeof / decltype，也不能期望numeric_limits提供有意义的值和组合集的有用信息（实际上，源代码中甚至没有标明“合法”组合，请考虑enum { A = 1, B = 2 }-是A|B程序逻辑中的“合法”）透视？）
   • 枚举的类型名称可能出现在RTTI，编译器消息等的各个位置。-可能有用，可能会混淆
   • 您不能在没有翻译单元实际看到值的情况下使用枚举，这意味着库API中的枚举需要在标头中公开这些值，make并且其他基于时间戳的重新编译工具在更改它们时会触发客户端重新编译（不好！ ）

2. consts：

   • 正确确定范围/标识符冲突问题得到了很好的处理
   • 强，单一，用户指定的类型
     • 您可以尝试“键入” #defineala #define S std::string("abc")，但常量避免在每个使用点重复构造不同的临时对象
   • 一个定义规则的并发症
   • 可以获取地址，创建对它们的const引用等。
   • 最类似于非const值，如果在两者之间切换，则可最大程度地减少工作和影响
   • 值可以放置在实现文件中，从而可以进行本地化的重新编译，并且只需客户端链接即可获取更改

3. #defines：

   • “全局”范围/更容易出现用法冲突，这可能会产生难以解决的编译问题和意外的运行时结果，而不是合理的错误消息；缓解这种情况需要：
     • 长的，模糊的和/或集中协调的标识符，对它们的访问不能从隐式匹配使用的/当前的/ Koenig查找的名称空间，名称空间别名等中受益。
     • 尽管最好的做法是允许模板参数标识符为单字符大写字母（可能后跟数字），但通常保留并期望其他使用不带小写字母的标识符，这是预处理器定义所期望的（在OS和C / C ++库之外）标头）。这对于使企业规模的预处理器使用保持可管理性很重要。可以期望第三方图书馆遵守。观察到这意味着将现有const或枚举迁移到定义或从定义迁移涉及到大小写的更改，因此需要对客户端源代码进行编辑，而不是“简单”重新编译。（就我个人而言，我将枚举的首字母大写但不使用consts，因此我也很想在这两个字母之间迁移-也许是时候重新考虑一下。）
   • 可能有更多的编译时操作：字符串文字串联，字符串化（取其大小），串联为标识符
     • 缺点是给定的#define X "x"和某些客户端用法ala "pre" X "post"，如果您希望或需要使X为运行时可更改的变量而不是常量，则可以强制对客户端代码进行编辑（而不仅仅是重新编译），而从const char*或const std::string给定它们，则过渡更容易已经迫使用户把串联操作（例如"pre" + X + "post"用于string）
   • 不能sizeof直接在定义的数字文字上使用
   • 无类型（与相比，GCC不会发出警告unsigned）
   • 一些编译器/链接器/调试器链可能不提供标识符，因此您将被简化为查看“魔术数字”（字符串，无论如何...）
   • 不能拿地址
   • 在创建#define的上下文中，替换值不必是合法的（或离散的），因为在每个使用点都会对它进行评估，因此您可以引用尚未声明的对象，取决于不需要的“实现”被预先包括在内，创建“常量”（例如{ 1, 2 }可用于初始化数组#define MICROSECONDS *1E-6等）（绝对不建议这样做！）
   • 一些特殊的东西，例如__FILE__和__LINE__可以合并到宏替换中
   • 您可以在#if条件语句中测试语句的存在和值，以有条件地包含代码（比后预处理“ if”功能更强大，因为如果预处理程序未选择则无需编译代码，则可以使用#undef-ine或redefine等）。
   • 替代文本必须公开：
     • 在其使用的翻译单元中，这意味着供客户端使用的库中的宏必须位于标头中，因此make，其他基于时间戳的重新编译工具将在更改它们时触发客户端重新编译（不好！）
     • 或在命令行上，需要更加小心以确保重新编译客户端代码（例如，提供定义的Makefile或脚本应作为依赖项列出）

我个人的看法：

通常，我使用consts并认为它们是常规用法中最专业的选择（尽管其他方法对老的懒惰程序员很有吸引力）。

如果这是一个C ++问题，并且它#define是替代问题，那么它是关于“全局”（即文件作用域）常量的，而不是关于类成员的。说到C ++中的此类常量，这static const是多余的。在C ++中const，默认情况下具有内部链接，因此没有必要声明它们static。因此，它实际上是关于const对#define。

最后，const最好使用C ++ 。至少因为此类常量是类型化的和作用域化的。除了极少数例外，没有任何理由更喜欢#define它const。

字符串常量BTW是此类异常的一个示例。使用#defined字符串常量，可以使用C / C ++编译器的编译时串联功能，如

#define OUT_NAME "output"
#define LOG_EXT ".log"
#define TEXT_EXT ".txt"

const char *const log_file_name = OUT_NAME LOG_EXT;
const char *const text_file_name = OUT_NAME TEXT_EXT;

PS同样，以防万一，当有人提到static const替代时#define，通常意味着他们在谈论C，而不是C ++。我想知道这个问题是否被正确标记了...

#define 可能导致意外结果：

#include <iostream>

#define x 500
#define y x + 5

int z = y * 2;

int main()
{
    std::cout << "y is " << y;
    std::cout << "\nz is " << z;
}

输出不正确的结果：

y is 505
z is 510

但是，如果将其替换为常量：

#include <iostream>

const int x = 500;
const int y = x + 5;

int z = y * 2;

int main()
{
    std::cout << "y is " << y;
    std::cout << "\nz is " << z;
}

它输出正确的结果：

y is 505
z is 1010

这是因为#define只需替换文本即可。因为这样做会严重破坏操作顺序，所以我建议改用常量变量。

使用静态const就像在代码中使用任何其他const变量一样。这意味着您可以跟踪信息的来源，而不是在预编译过程中只需在代码中替换的#define。

您可能想看看有关此问题的C ++ FAQ Lite：http : //www.parashift.com/c++-faq-lite/newbie.html#faq-29.7

• 键入静态const（具有类型），编译器可以检查其有效性，重新定义等。
• #define可以不定义地重新定义。

通常，您应该首选静态const。它没有缺点。预处理程序应主要用于条件编译（有时可能用于真正肮脏的度量标准）。

#define建议不要使用preprocessor指令定义常量，不仅要在中使用C++，而且要在中使用C。这些常量将没有类型。甚至在C有人提出使用const常量。

请在这里查看： 静态const vs定义

通常使用const声明（注意，它不必是静态的）才是可行的方法

总是比其他一些工具（如预处理器）更喜欢使用语言功能。

ES.31：请勿将宏用于常量或“函数”

宏是错误的主要来源。宏不遵循通常的作用域和类型规则。宏不遵循通常的参数传递规则。宏确保人类读者看到的东西不同于编译器看到的东西。宏使工具构建复杂化。

来自C ++核心准则

如果要定义要在类的所有实例之间共享的常量，请使用静态const。如果常量是特定于每个实例的，则只需使用const（但请注意，该类的所有构造函数都必须在初始化列表中初始化此const成员变量）。