17

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

链接：

删除概念——Danny Kalev（关于删除概念的决定）

简化概念的使用——Bjarne Stroustrup（关于现在的概念问题）

长杆越来越长——Martin Tasker（关于如果必须修复概念对 C++0x 时间表的影响）

C++0x“删除概念”决定- Stroustrup 关于 Dobbs 博士的问题

旅行报告：退出概念，大约 18 个月后的 ISO C++ 最终草案- Herb Sutter

概念在 C++0x 岛上获得投票- Jeremy Siek 捍卫当前的概念规范

法兰克福发生了什么？- Doug Gregor on C++Next（关于概念的历史和删除）。

4

9 回答 9

27

当然，这会影响其他功能，并且似乎会再次打开标准。

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

无论如何....在剩下的 C++0x 中，我想不出还有什么我想删除的。我同意他们关于概念的决定。Stroustrup 的论文确实概述了一些严重的问题，当前的概念规范无疑会简化模板错误消息，但这样做会大大降低泛型编程的有用性——我不愿意为此付出代价。

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

但除此之外，我认为 C++0x 状况良好。其余的新功能看起来都值得。

当然，我很想删除很多现有的功能。主要是vector<bool>专业。还有其他一些没有成功的流行特性示例（export 关键字、异常规范），但向量特化是其中唯一一个不可忽视的。只要我们不尝试导出模板，关键字是否存在（并且不是由编译器实现）都没有关系，我们可以避免使用异常规范，但是每次我们都需要一个布尔向量，我们被当前标准中愚蠢的过早优化所困扰。

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

当然，也可以抛弃很多旧的 C 垃圾，但最近，我发现我真正希望看到的一个变化是……抛弃 Iostreams 库。扔掉它，并基于泛型编程构建一个新的 STL 风格的 I/O 库。

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

扔掉 IOstreams，开发一个现代的替代品，C++ 将得到极大的改进。

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

于 2009-07-21T13:29:20.907 回答
10

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

于 2009-07-20T19:31:09.990 回答
5

我认为应该将两件事添加到 C++0x 中，我自己都想到了这两件事，然后发现其他人之前曾建议过它们，但似乎它们不会发生。

1. 默认移动构造函数和移动赋值运算符

编写移动构造函数是手动且容易出错的活动，如果添加成员，则必须将其添加到移动构造函数和赋值运算符中，并且std::move必须认真使用。这就是为什么我认为这些函数应该是 defaultable。

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

编辑（2009-10-01）：看起来这毕竟会发生。

2.重写表达式模板的类型推导

表达式模板通常定义不应该直接使用的类型，一个典型的例子是 的返回值std::vector<bool> operator[](size_type n)，如果auto或decltype用于这种对象可能会出现意外行为。因此，一个类型应该能够说出它应该被推断为什么类型（或防止使用= 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;
     }
于 2009-07-21T05:55:36.817 回答
5

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

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

于 2009-07-20T19:25:49.563 回答
3

对我来说，问题不在于应该去除哪些其他功能，而在于删除概念后其他功能会有多复杂。那以及在没有概念的情况下重新表述其余功能需要多长时间。

许多功能都假设概念会被语言接受，并且措辞是用概念来表达的。（我想知道是否有任何提议的功能取决于概念）。

我还想知道其他库将如何发展（想想 boost::type_traits）以占据概念留下的利基市场。可以根据应用于类型参数的特征来实现所提供的部分概念（即使以更繁琐的方式）。

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

RIP 概念。

于 2009-07-20T19:34:36.160 回答
2

用概念做任何你想做的事，但看在上帝的份上，保留线程和原子，我们绝对需要它们。也许添加线程组并支持协作线程（也称为纤维）。IMO 这些远比概念重要，因为每个人都使用/即将使用线程。

于 2009-08-17T18:17:55.813 回答
1

我想删除=delete.

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

更不用说在delete关键字的（现在）两个含义之间混淆人们了。

于 2010-02-24T14:32:59.163 回答
1

去掉模板代码上的错误信息页面！

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

于 2009-07-20T19:48:15.277 回答
0

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

另一方面，我有点喜欢概念，尽管我肯定不会每天都使用它们。

于 2009-07-20T19:29:07.437 回答