现代C ++的实验功能对长期项目是否可靠? [英] Are the experimental features of modern C++ reliable for long-term projects?

问题描述

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

I have a project that currently uses C++11/14, but it requires something like std::filesystem, which is only available in C++17, and hence I don't have a chance to currently use it. I see, however, that it's available in my current compiler as std::experimental::filesystem. Is it a good idea to use experimental features, assuming that I could in the future add something like:

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

我担心的是:

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

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

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

Maybe there's more things to wonder about. Why should I or should I not use them? I'm puzzled with a new project and don't know what to decide.

推荐答案

1. 是否可以确保所有兼容的编译器都具有相同的实验功能?

否，实验性功能是可选的.

No, experimental features are optional.

1. 实验功能是否容易发生重大变化，使其变得不可靠?

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

Yes, the C++ committee might even decide to abandon a feature or in the process of standardization a defect might come up that would force a feature to change.

通常，依靠实验功能不是一个好主意.实验功能正是该词所说的(即可以进行实验).

Generally, it's not a good idea to depend on experimental features. Experimental features are exactly what the word says (i.e., to experiment with).

这篇关于现代C ++的实验功能对长期项目是否可靠?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！