将命名空间实验注入std

将名称空间std::experimental注入std如下所示是不好或好的parctice ？

namespace std
{
namespace experimental
{
}
using namespace experimental;    
}

#include 

int main()
{
    std::optional< int > o;
    return 0;
}

甚至以更现代的形式:

#if __has_include()
# include 
#elif __has_include()
# include 
namespace std
{
using namespace experimental;    
}
#else
#error !
#endif

int main()
{
    std::optional< int > o;
    return 0;
}

引入std::experimental"子命名空间" 的意图很明确,因为std::experimental目前包含大量新库.我认为它们很可能会在namespace std没有任何实质性更改的情况下迁移到目前用户代码可以依赖于此(我完全错了吗？).否则,所有这些代码都应该重构,std::experimental::以便std::将来改变.这不是什么大不了的事,但可能有理由不这样做.

问题是关于生产代码和不太严肃的代码.

在工作中,我花了很多时间来对抗这种投机复杂性(我正在寻找一个表征行为特征的好短语,这是迄今为止我提出的最好的).

在我看来,你介绍的复杂性和危险性,现在到你的代码,以避免在未来重构.这已经足够糟糕,但在这种特殊情况下,我甚至会说重构是一个糟糕的单词选择 - 它不是简单的文本替换重构.

通过代码删除std :: experimental's(或者更改为std ::或std :: something_else)实际上只是一个文本替换.在最好的情况下,您正在编辑或ide中查看快速命令.在最糟糕的情况下,你正在考虑花几个小时写一个正则表达式 - 可能在你的编辑器中,也许在PERL或Ruby ...

那些std :: experiment表示你正在使用实验性功能,并且在你的代码中有一个明确的声明是很好的.如果某些图书馆进入标准,合格的程序员可以快速轻松地进行必要的文本替换.如果您的文本编辑技能不能胜任任务,请不要破解语言 - 提高文本编辑技能.这是一个机会.

更通俗地说,编写最简单,最干净的代码,满足您现在的需求,并随时准备好在情况发生变化时进行更改.这通常会产生更灵活的代码,比现在的推测更能支持您真正的未来需求.

听起来不错.

首先,这是未定义的行为.N4140标准草案说:

[namespace.std]/1:如果C++程序将声明或定义添加到命名空间std或命名空间中的命名空间std,则除非另有说明,否则C++程序的行为是未定义的.[...]

using-directive是一种声明,因此UB是当天的订单.

其次,事情std::experimental很容易发生变化.您可能会发现,当事情被移动到std适当的位置时,您的代码仍会编译,但不会以完全相同的方式运行.这只是一个问题,特别是在生产代码中.