是`使用命名空间std :: literals`安全吗？

Question

一般来说,using namespace在全球范围内被认为是一种不良做法.但是,根据cppreference,在_用户定义的文字的情况下,不以下划线()开头的标识符保留用于标准库.

标识符,用作将调用此函数的用户定义文字的ud后缀.必须以下划线_开头:不以下划线开头的后缀保留给标准库提供的文字运算符.

这是否意味着我可以安全地using namespace std::literals;在全球范围内做？

Answer 1

这些用户定义的文字是相当新的。您必须了解这里的标准主体；他们没有实际使用的经验（不像Boost）。因此，他们想出了一种保守的方法：一方面，预定义后缀位于namespace std，另一方面用户定义的文字必须以 开头_。

这确实在中间留下了一个开放空间：后缀不是以全局命名空间开头_，而是在全局命名空间中定义的。当我们获得现有文字的经验时，可能会决定由谁来定义这些文字。

因此，为了让您的代码面向未来，无论未来标准中做出什么选择，您都不应该给其他人带来太多问题。但这是否意味着“避免using在全局命名空间中使用”？不可以。每个翻译单位都可以做出自己的选择。在您自己的 .cpp 文件中，执行您喜欢的操作。但您不应该影响其他翻译单元。因此实际的规则是：

using namespace std::literals在 headers 中不安全。

Answer 2

从标准的角度来看，当他们说某些名称由标准库保留时，如果您违反约定，我会将其解释为不能保证已定义的行为。另一方面，某些编译器可能不会让您对违反规定的约定负责。例如，gcc如果未以下划线开头的文字运算符标识符，则给出警告，而不是错误。

这里更好的表述不是是否包括

using namespace std::literals;

在全局范围内是一种安全的做法，但它是否是一个好的防御性编程策略。置于using namespace foo全局范围内并不是防御性编程，因为这样做至少部分地违背了命名空间的目的。

现在，考虑到您的特定代码库，您可能永远不会遇到这样做的问题。但这只能由你来判断。如果您打算与其他人共享您的代码，我建议您进行防御性编程，以便您的代码的不知情用户不会有机会遇到意外情况（即使他们不遵循所有约定，或者如果未来会修改标准）。