Question

您可能已经听说过，C ++标准委员会的最后一次会议投票决定从下一个C ++标准中删除概念。当然，这会影响其他功能，并且似乎再次打开标准。如果是这种情况，您认为哪些其他功能应该被删除（或添加），为什么？

链接：

Removal of Concepts - Danny Kalev（关于删除概念的决定）

Simplifying the use of Concepts - Bjarne Stroustrup（关于他们现在看来的概念问题）

The Long Pole Gets Longer - Martin Tasker（关于如果必须修复概念，对C ++ 0x计划的影响）

The C++0x "Remove Concepts" Decision - 关于Dobbs博士问题的Stroustrup

Trip Report: Exit Concepts, Final ISO C++ Draft in ~18 Months - Herb Sutter

Concepts Get Voted Off The C++0x Island - Jeremy Siek捍卫当前的概念规范

What Happened in Frankfurt? - Doug Gregor关于C ++ Next（关于概念的历史和删除）。

Answer 1

当然，这会影响其他人功能，似乎扔了标准大开再次。

几乎没有。他们仍然希望很快完成标准，这是删除概念的主要原因之一。让它对不相关的变化“敞开大门”只会抛弃他们通过放弃概念而获得的一切。

无论如何....在剩余的C ++ 0x添加中，我想不出任何我想删除的内容。我同意他们关于概念的决定。 Stroustrup的论文确实概述了一些严重的问题，当前的概念规范无疑会简化模板错误消息，但它会通过大幅降低泛型编程的实用性来实现 - 这是我不愿意付出的代价。

当我第一次阅读那篇论文时，它吓到了我，因为我认为在对规范进行严格修改的过程中为时已晚。事实证明事实并非如此，委员会愿意采取戏剧性的行动。

但除此之外，我认为C ++ 0x处于良好状态。剩下的新功能看起来都值得。

当然，我希望删除大量现有功能。主要是vector<bool>专业化。还有其他一些流行的功能示例（导出关键字，异常规范），但是矢量专精化是唯一一个不可忽略的功能。只要我们不尝试导出模板，关键字存在（并且不是由编译器实现）并不重要，我们可以避免使用异常规范，但每次我们需要bools向量时，我们被愚蠢的过早优化所困扰，这种优化已经进入当前的标准。

不幸的是，似乎他们已经放弃了删除它。（最后我检查过，甚至没有弃用）。

当然，很多旧的C cruft也可能被抛弃，但最近，我发现我真正喜欢看到的一个变化就是......放弃了Iostreams图书馆。抛弃它，并基于通用编程构建一个新的STL样式的I / O库。

目前的OOP风格的Iostreams库是丑陋，缓慢，过于复杂和不灵活的。定义新流涉及太多伏都教，涉及的标准流类型太少，灵活性太小（让我意识到库有限的问题，是我需要从字符串中提取浮点数。这很容易用stringstream做，但是如果你需要经常这样做，你不希望每次都复制输入字符串（就像字符串流一样） - 哪个是在现有迭代器范围内工作的流？或者是原始数组，甚至？）

抛弃IOstreams，开发现代替代品，C ++将得到极大改进。

也许也可以对字符串类做些什么。它的工作方式与现在一样好，但实际上，大量的成员函数是什么？他们中的大多数会更好地工作，并且更自由，作为自由功能。太多的标准库特别依赖于字符串类，当它原则上可以使用任何容器，甚至是迭代器（std::getline时，我正在看着你）

Answer 2

就个人而言，我希望C ++最终脱离C.不再需要预处理器，不再有头文件。我基本上想要D，但是没有使用STL的所有东西。

Answer 3

没有，我认为草案的其余部分很棒 - 可以独立正确实施的大量非常小的部分，允许供应商发展到完全支持并允许用户采取“购物清单”方法。

与合同的情况完全不同，因为它们就像一个全新的并行类型系统，并且很可能导致不同的编译器最终出现自己的向后兼容性问题，与Web浏览器中的CSS非常相似。 / p>

Answer 4

我认为应该向C ++ 0x添加两件事，我自己已经考虑过这两件事，然后发现其他人之前已经提出过它们，但看起来它们似乎不会发生。< / p>

<强> 1。默认移动构造函数和移动分配操作符

编写移动构造函数是一种手动且容易出错的活动，如果添加了成员，则必须将其添加到移动构造函数中，并且必须虔诚地使用赋值运算符和std::move。这就是为什么我认为these functions should be defaultable。

movable(movable&&) = default;
movable& operator=(movable&&) = default;

编辑（2009-10-01）：毕竟看起来这是going to happen。

<强> 2。覆盖表达式模板的类型扣除

Expression templates经常定义不应该直接使用的类型，一个恰当的例子是return value of std::vector<bool> operator[](size_type n)，如果auto或decltype用于此类对象意外行为可能随之而来。因此type should be able to say what type it should be deduced to be（或使用= delete语法阻止扣除）。

添加载体的例子。

// lazy evaluation of vector addition
template<typename T, class V1, class V2>
class vector_add {
     V1& lhs_;
     V2& rhs_;
public:
     T operator[](size_t n) const
     { return lhs_[n] + rhs_[n]; }
     // If used by auto or decltype perform eager creation of vector 
     std::vector<T> operator auto() const 
     {
         if (lhs_.size() != rhs_.size()) 
             throw std::exception("Vectors aren't same size");
         std::vector<T> vec;
         vec.reserve(lhs_.size());
         for (int i = 0; i < lhs_.size(); ++i)
            vec.push_back(lhs_[i] + rhs_[i]);
         return vec;
     }

Answer 5

对我而言，问题不在于应该删除其他功能，而是删除概念后其他功能的复杂程度。那些以及在没有概念的情况下重新描述其余特征需要多长时间。

许多功能假设概念将被接受到语言中，而措辞则以概念的形式表达。（我想知道任何提议的功能是否取决于的概念）。

我也想知道其他图书馆将如何发展（想想boost :: type_traits）来占据概念留下的利基。在应用于类型参数的特征方面，可以实现所提供概念的一部分（即使以更加繁琐的方式）。

对我来说，概念中最重要的一点就是编译错误的表达式，这是当今C ++最受批评的地方之一。

R.I.P。概念

Answer 6

做任何你想要的概念，但为了上帝的缘故保持线程和原子，我们绝对需要它们。也许添加线程组并支持协作线程a.k.a。fibers。 IMO这些远比概念重要，因为每个人都会使用/很快就会使用线程。

Answer 7

删除模板代码上的错误消息页面！

IIRC概念应该解决一个大的C ++编码器问题：STL的人类可读错误消息。这个问题没有解决的坏消息。

Answer 8

我想删除=delete。

已经有一个共同的，被接受的成语来实现相同的效果（将有问题的函数声明为私有）。我认为这个特性会产生很多'我用=delete来从我的派生类中删除一个基类函数，但它仍然可以使用基类指针'问题来调用。

更不用说在delete关键字的（现在）两个含义之间让人感到困惑。

Answer 9

未命名的函数/ lambda函数让我很紧张。函数对象非常好并且是显式的，因此更容易阅读和查找。

另一方面，我有点喜欢概念，但我当然不会每天都使用它们。

C ++ 0X概念已经消失。还应该使用哪些其他功能？

9 个答案: