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

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

链接:

删除概念 - Danny Kalev(关于删除概念的决定)

简化概念的使用 - Bjarne Stroustrup(关于现在看来的概念问题)

长杆变得更长 - 马丁Tasker(如果必须修复概念,对C++ 0x的时间表的影响)

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

旅行报告:退出概念,约18个月的最终ISO C++草案 - Herb Sutter

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

法兰克福发生了什么？ - Doug Gregor关于C++ Next(关于概念的历史和删除).

1> jalf..：

---

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

几乎不.他们仍然希望尽快完成标准,这是删除概念的主要原因之一.对无关的变化"敞开大门"只会抛弃他们通过放弃概念而获得的一切.

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

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

但除此之外,我认为C++ 0x处于良好状态.其余的新功能看起来都很值得.

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

不幸的是,似乎他们已经放弃了删除它.(最后我查了一下,甚至都没有弃用).

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

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

抛出IOstreams,开发现代替代品,C++将得到极大改进.

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

---

真棒,非常好的答案!(好吧,其中一些是为了克服15-char的事情)

---

是的,iostream是可怕的 - 我们应该真的得到更好的东西.事实上,我希望看到一个更好(和更小)的字符串类,但这不会发生.

---

如果你想要一些他们失败的例子,这里有一个非常不完整的清单:cout <<"hello"<<"world"不会原子地写出来.其他线程可能会在"你好"之后跳入并打印出来.这使得以线程安全的方式组合输出相当棘手.wifstream实际上无法处理宽字符.它读取char,并在内部将它们扩展为wchar_t.istream有一些非常奇怪的方法来处理剩余的空白(每个初学者都在努力完成简单的任务,比如"等待输入被按下,然后阅读更多输入".

---

我发现你可以在第一个单词后插入15个空格.它们在显示时被压缩到一个空格,但是你超过了15个字符限制:D

---

这两个(iostreams,string)都是纯库概念.这真的是像boost这样的东西可以进入它自己的东西.如果在那里开发了有价值的替换库,那么它们很可能会"标准化"(正如很多其他的boost库一样).

2> Randolpho..：

---

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

---

如果你想要D,使用D,而不是C++.

---

我喜欢头文件.

---

对于新标准,没有任何破坏向后兼容性的内容.外部有太多现有的C++代码需要工作.

---

我不会说我是一个宏粉丝,但有一些我很难用其他任何现有的机制来代替.

---

有些东西可以很好地利用预处理器宏.我在考虑boost :: bind/boost :: function以及其他可能...

---

@Paul - 有些人付出了很多钱被鞭打!

---

但愿如此.烘烤C预处理器应该符合为诺贝尔和平奖所做的标准委员会的资格.社会如何应对突然爆发的生产力？

---

@Earwicker然后包括(哈哈)我的一点 - 我也喜欢他们.

3> Daniel Earwi..：

---

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

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

4> Motti..：

---

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

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

编写移动构造函数是一种手动且容易出错的活动,如果添加了成员​​,则必须将其添加到移动构造函数和赋值运算符中,并且std::move必须虔诚地使用.这就是为什么我认为这些功能应该是违约的.

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

编辑(2009-10-01):看起来这毕竟会发生.

2.覆盖表达式模板的类型扣除

表达式模板通常定义不应该直接使用的类型,一个例子就是返回值std::vector operator[](size_type n),如果auto或decltype在这种对象上使用,则可能会发生意外行为.因此,类型应该能够说出应该推断出的类型(或者使用= delete语法来防止推断).

添加载体的例子.

// lazy evaluation of vector addition
template
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 operator auto() const 
     {
         if (lhs_.size() != rhs_.size()) 
             throw std::exception("Vectors aren't same size");
         std::vector vec;
         vec.reserve(lhs_.size());
         for (int i = 0; i < lhs_.size(); ++i)
            vec.push_back(lhs_[i] + rhs_[i]);
         return vec;
     }

---

问题是表达式模板被设计为在一个语句中工作,这意味着它们可能存储对两个操作数的引用,如果其中一个是临时的,它可能在使用`vector_add`实例之前被销毁.

---

@DanielEarwicker:http://coliru.stacked-crooked.com/a/0b3f7d571659c9a8