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

时间:2018-03-27 01:42:42

标签: c++ user-defined-literals

通常,全局范围内的using namespaceconsidered as a bad practice。但是,根据cppreference,在用户定义的文字的情况下,不以下划线(_)开头的标识符保留给标准库。

  

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

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

2 个答案:

答案 0 :(得分:3)

这些用户定义的文字很新。你必须在这里理解标准组织;他们没有实际使用经验(与Boost不同)。因此他们提出了一种保守的方法:一方面,预定义的后缀位于namespace std,另一方面,用户定义的文字必须以_开头。

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

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

using namespace std::literals 标题中不安全

答案 1 :(得分:0)

从标准的角度来看,当他们说标准库保留了一些名称时,如果你违反惯例,我会将其解释为没有定义行为的保证。另一方面,一些编制者可能不会要求您违反规定的约定。例如,gcc给出一个警告,而不是错误,因为没有使用下划线启动文字运算符标识符。

这里更好的表述不是包括

using namespace std::literals;

在全球范围内是安全的做法,但它是否是一个很好的防御性编程策略。将using namespace foo放在全局范围内并不是防御性编程,因为这样做至少部分地破坏了命名空间的目的。

现在,根据您的特定代码库,您可能永远不会遇到问题。但这只是你的判断。如果您打算与他人分享您的代码,我建议您采取防御性编程方式,这样代码的不知情用户就无法遇到意外情况(即使他们不遵守所有约定,或者将来修改标准。)

相关问题