命名空间别名与定义的实际优势 [关闭]答案

【问题标题】：Real-world advantage of namespace aliases vs defines [closed]命名空间别名与定义的实际优势 [关闭]
【发布时间】：2013-01-31 14:55:53
【问题描述】：

编辑：我打算重构一些代码，并将define 替换为命名空间别名。我不能这样做只是因为“宏是邪恶的”。我需要解释为什么我想要做出改变，如果我不这样做，什么会出错。

抛开“宏是邪恶的”的立场不谈，#define 在命名空间别名上的缺点是什么？

获取代码

#define MY_NAMESPACE my_namespace

对

namespace MY_NAMESPACE = my_namespace;

使用别名的原因不在问题范围内。您还可以假设命名空间的名称足够独特以至于它不会出现在其他任何地方（即它只是引用该命名空间，它不能——现在不能，将来也不能——引用变量或类或无论如何），所以那里不会有歧义。

【问题讨论】：

宏是邪恶的。
在相互竞争的假设中，应该选择最简单的一个。
“你也可以假设...”：使用适当范围的语言级标识符，而不是让预处理器在不考虑范围的情况下吐出所有代码，你不需要做任何这样的假设。
@LuchianGrigore：不，完全一样。在任何其他情况下，有人可能会考虑#define，他们可以做出相同的假设，但这并不能保证两个月后您不会开始使用在某些标题中包含相同单词的库，或者有人可能会添加同名的变量...问题和答案完全相同，#define 是一把锤子，可以敲钉子和螺丝（并在此过程中粉碎任何其他东西），命名空间别名是适用的螺丝刀仅限螺丝。
我读到这个问题是“我怎样才能说服某人在时间和金钱方面赞助我，用他们可能看不到意义的更好的解决方案来替换代码（可能已经工作）的，可能不会立即带来切实的好处，甚至可能——因为每次代码更改都涉及风险——会在短期内增加问题的风险？” - 如果是沿着这些思路，那么我认为这是一个建设性的问题。我每天都面临这些问题。

标签： c++ namespaces macros coding-style c-preprocessor

【解决方案1】：

在这种特殊情况下，这取决于。如果使用命名空间别名对于所有的通常的原因。但两者做的事情完全不同。你无法使用其别名打开命名空间，即：

namespace XYZ_ver1 {}
namespace XYZ = XYZ_ver1;

namespace XYZ {     //  Illegal!
}

这适用于宏；其实可以定义宏在命名空间出现之前。如果你需要这个，那么你需要使用宏。

【讨论】：

太棒了！我从来没有想过这个。
我选择将此视为使用别名的优势 - 您限制扩展命名空间（除非您使用原始名称）
@LuchianGrigore 同意。我在库代码本身中定义了一个宏，这样我就不必更改XYZ_ver2 中的每个XYZ_ver1，但是我在客户端界面中提供了别名，因此客户端无法（意外或以其他方式）添加给它。（但我的观点是，至少部分是，他提出的改变不是止痛药。）

【解决方案2】：

一般来说，我看到命名空间别名的唯一优势是它们可以在任何地方。举个例子：

namespace a
{
    namespace that_is_a_great_namespace
    {
        namespace b = that_is_a_great_namespace;
    }
}

namespace that_is_a_great_namespace {}

您将无法定义将a::that_is_a_great_namespace 转换为a::b 而没有副作用的宏。在这里，that_is_a_great_namespace 也将转换为 b。在这些情况下，命名空间别名有助于解决名称冲突。

但是，如果您已经使用 #defines 并且它已经有效，那么针对这种罕见的情况重构您的代码可能没有用。

【讨论】：