我的理解是,表达模板作为一种技术早在1998年最初的C ++ Standard之前就被发现。为什么不使用它们来提高像std::string
and stream 这样的几个标准类的性能?
operator+
,则可以实现O(n)
重复分配并将零冗余分配归零,这仍然比右值引用更快。另外,您可以通过在write上复制而不只是“在非常量索引上” 复制来优化例如COW实现。还有其他应用程序也可以使用表达式模板来提高性能和语义。
我的理解是,表达模板作为一种技术早在1998年最初的C ++ Standard之前就被发现。为什么不使用它们来提高像std::string
and stream 这样的几个标准类的性能?
operator+
,则可以实现O(n)
重复分配并将零冗余分配归零,这仍然比右值引用更快。另外,您可以通过在write上复制而不只是“在非常量索引上” 复制来优化例如COW实现。还有其他应用程序也可以使用表达式模板来提高性能和语义。
Answers:
表达模板最初由Todd Veldhuizen于1995年6 月在《C ++ Report》杂志的一篇文章中发表。到那时,标准委员会已经在将STL添加到C ++标准中进行了大量工作,这项任务本身就将标准延迟了一两年。(STL于1993年提交给委员会,并于1994年正式提出。又花了四年的时间来完成该标准。)
鉴于C ++标准化委员会是一群志愿者,其中有些人甚至没有得到付费的公司的支持。费用,我认为没有人可以使用任何资源来为C ++标准添加另一个想法。
同样,1995年只是Veldhuizen文章发表的一年。为了使这项技术变得众所周知和被认可,还需要花费几年的时间。(STL的想法可以追溯到70年代,Ada实现是在80年代后期完成的,C ++实现的工作必须在1990年左右开始,并且又花了三年的时间才找到实现C ++标准化的方法。委员会。)
有,然而,从托德的文章,直到在标准的最终投票短短三年。花费很少的时间来整合仍然是全新的且基本上未经测试的想法。
此外,表达式模板是一种模板元编程,它使编译器比相对“简单”的STL更加注重压力。从我的记忆中,即使在1998年标准发布时,我们都没有一个可以编译所有STL的编译器。
鉴于标准化委员会的主要目标之一是标准化已建立的惯例(而不是严格遵循这一惯例),因此,那时的表达模板永远都不应放在议程上。
std::string
iostream不在STL中。
std::string
被改为把它变成一个STL容器,BTW)
一个简单的答案是:您显然没有为此游说。我也没有,因为我有(也有)自己的议程,其中不包括表达式模板。同样,特别是用于字符串的接口已经在尝试提供过多的母带,从而产生了一个用于所有事物并且对蛾类有益的类。
标准库已经有一个std::valarray
家族,旨在支持一个表达模板样式的实现。据我所知,它还不能完全解决问题。导致此问题的一个问题是,游说将其包含在标准中的半烘焙版本的人们在将其包含进标准时就停止了工作。人们曾尝试营救它(例如,David Vandevoorde,Matt Austern,我在斯德哥尔摩会议上做了大约一天的研究),但最终没有人对此感兴趣。
:)
现在被称为“表达模板”的技术至少是在1994年由Todd Veldhuizen和我本人(独立地)发现的(Todd的文章来自1995年,但是要花一些时间才能出版,我自己的作品最初显示在comp.lang.c ++中)。
正是由于这个问题,我实际上开始参加C ++委员会会议。我在1996年3月的第一届圣克鲁斯会议上向委员会介绍了该技术和std :: valarray的完整重新设计。这被认为太大了,但是正如Dietmar所暗示的那样,我们在随后的见面会上表达了一些话。在斯德哥尔摩,使表达式模板可用于实现std :: valarrray。令我惊讶的是,这些词仍然存在:请参阅http://wg21.link/N4727中的 [valarray.syn] 29.7.1小节中的3-6段。
我最好的猜测是,早在1998年就没有编译器能够编译表达式模板。
:->
另外,他们无法足够快地对其进行改进,因此使用快速改进的模板技术变得越来越困难。当VC7.1发布并且更加合规时,这使Borland丧命。