现代C ++的实验功能对长期项目是否可靠？

Question 1

我有一个当前使用C ++ 11/14的项目，但是它需要类似的东西std::filesystem，它仅在C ++ 17中可用，因此我目前没有机会使用它。但是，我看到它在我当前的编译器中可用std::experimental::filesystem。使用实验性功能是否是一个好主意，假设我将来可以添加以下内容：

#ifdef CXX17 //if this is C++17
std::filesystem::something ...;
#else
std::experimental::filesystem::something ...;
#endif

我担心的是：

1.是否保证所有兼容的编译器都具有相同的实验功能？

2.实验功能是否容易发生重大变化而使其不可靠？

也许还有更多事情想知道。为什么我应该或不应该使用它们？我为一个新项目感到困惑，不知道该怎么决定。

Question 2

是否保证所有兼容的编译器都具有相同的实验功能？

不，实验功能是可选的。

实验功能是否容易发生大的变化而使其不可靠？

是的，C ++委员会甚至可能决定放弃某个功能，或者在标准化过程中可能会出现缺陷，从而迫使功能发生更改。

通常，依靠实验功能不是一个好主意。实验功能正是这个词所说的（即要进行实验）。

Question 3

在CppCon 2016（YouTube）上的“ C ++标准库专家组”演讲中，听众中有人提出了一个问题，即该名称可能使experimental用户害怕使用命名空间中的任何内容：

你们是否认为[std::experimental名称空间的内容]生产已经准备就绪，是否可以提出一个论点，[它]在接下来的3年内有效地准备生产，也许您必须在3年后更改代码？

Wong（SG5和SG14主席以及Concurrency TS的编辑）首先提出了这个问题：

我认为委员会内部已经就生产准备就绪达成了强烈共识。正如我之前说过的，在大多数情况下，有99％的空气会掉进去。您可以理解为什么我们要在这样的上下文中放置大型功能，大型功能组，以免打扰整个图书馆系统的其余部分，但也使您更轻松地使用它。现在，您可以使用一个特定的Concepts标志打开GCC，您知道，这实际上使您更容易将其细分。

随后，Alisdair Meredith（LWG的前任主席）进行了跟进：

我将在这里采取相反的立场。作为标准工作组WG21的召集人，赫伯[萨特]说的一件事是，当我们确定TSes的发展方向时，他认为TSes不会成功，除非我们未能提出建议。意味着我们还没有足够的实验性，对于我们使用TS的目的没有足够的野心。我们确实希望experimental暗示是的，这些事情可能会发生变化，我们没有约束力，我们可能会出错。这是为了降低我们认为雄心勃勃且可以达到的事物的壁垒。现在，该标准似乎处于三年发布周期，我们应该更加雄心勃勃地投入真正的实验性功能进入TS，也许可以更快地将其推进到主要标准本身。但是，对于我们在接下来的几次[C ++标准委员会]会议上进行讨论，这将是一个有趣的话题。

Stephan T. Lavavej（Microsoft STL实现的维护者）最后回应：

区分接口的实验性和实现的实验性很重要，因为当您说“生产就绪”时，这意味着什么？通常，“准备就绪”时，您会想到有关实现的内容。…中的某些实现完全有可能std::experimental是防弹的。[...]类似于<random>TR1中的标头，在TR1中确实非常好，并且您可能对此有绝对的防弹实现，但事实证明该接口混乱了在[...] C ++ 11发行之前和[...]如果我们早就知道现在该怎么做，则在experimental向人们发出更好的信号时说：“嘿，也许您不想使用std::experimental::variate_generator 因为，哈哈，它将在C ++ 11中消失”。

因此，似乎标准库开发人员和委员会成员之间存在某种愿望，至少在将来，std::experimental命名空间的内容本质上应该是真正的“实验性”，不应将某些std::experimental遗嘱视为理所当然。使其成为C ++标准。

据我了解，不，这取决于标准库供应商是否为其提供各种功能的实现std::experimental。

Question 4

“实验性”是一个稍微夸张的术语。该filesystem库起源于Boost，并在那里进行了几次迭代，然后才提交给ISO。

但是，ISO标准故意非常保守。称其为实验性意味着ISO明确表示不会保证命名会保持稳定。很明显，将来您将需要重新寻址您的代码。但是了解ISO的情况下，很可能会有指导。

至于编译器之间的兼容性，希望它是合理的。但是会有很多情况（例如，考虑Windows驱动器相对路径），这就是为什么将来的标准可能会破坏您现有的代码的原因。理想情况下，当且仅当您依赖于这种极端情况时，它才会破坏您的代码，但这不是保证。

Question 5

也许还有更多事情想知道。

需要考虑的几点：

您的项目有多平台？如果只涉及一个编译器，则可以检查其实现并跟踪记录以确定。或问他们！
您的代码库有多大？变化的影响有多大？
API /库/功能提供的功能对您的项目而言有多重要？
有哪些选择？
- 使用实验性功能，然后在代码标准化时对其进行修改以适应修改。可能像删除操作一样容易，也可能experimental::像强迫解决方法一样困难。
- 添加一个抽象层（Serge Ballesta注释）。如果实验性功能更改，您的重写将被隔离。对于标准功能，它可能会过大（std :: filesystem已经是抽象层...）。
- 使用其他API /库。同样的问题：成熟吗？健壮性？稳定性？可移植性？便于使用？特征？
如果是std :: filesystem（或联网TS），则可以使用boost :: filesystem（或者boost :: asio）作为替代方案或回退，以防experimental失败或消失。