为什么限制关键字不是c++的一部分

Why is the restrict keyword not part of C++?

本文关键字：c++ 一部分 关键字 为什么      更新时间：2023-10-16

标题说明了一切。我很好奇为什么限制关键字不是c++的一部分?我对c++了解不多，而且我仍然无法在网上找到任何可以阻止此功能的理由。有人知道，如果c++标准像C语言那样使用这个关键字，会发生什么可怕的事情吗?还是根本不需要?

更多的解释:这不是关于使用它，也许我一辈子都不会从这个关键词中得到任何好处。这个问题只是出于好奇，因为自1999年以来，restrict一直是C的一部分，也就是15年了。

阅读下面的内容:我对技术原因感兴趣，而不是像"他们只是不喜欢，它不够酷"这样的意见

在c++中定义"restrict"有几个问题，其中一些在WG文件N3635中列出:http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3635.pdf "Towards restrict-like semantics for c++ "

c++中限制的一些可能的问题是:

  • 用"this指针"限制类成员和间接关联
  • 将限制限定符传入函数、函式、lambdas和模板
  • 函数内部限制指针值的转义
  • 重叠数组成员，跨步

文档还列出了几个对c++具有有限"restrict"支持的c++编译器。

在N3635中还有一个有趣的历史注释，关于不包含restrict to c++:

在Mont Tremblant会议期间审查c++中包含的C99特性时，考虑了restrict，但正在等待论文提案，尽管没有提出....

Restrict是C99的一个特性，它从来没有被设计成在类抽象中工作，它可能与指针在c++中不常见. ...有关它是为C语言的细粒度混叠而设计的，但对于c++中基于类型的混叠设计得不太好

不是要贬低osgx的答案，但是-有一篇更最新的论文，N3998由Finkel, Tong, Carrouth, Nelson Vandevoode和Wong于2014年5月发表:

面向c++的类限制混叠语义

以及2018年更新的一个:

[[assert: std::disjoint(A,nA, B,nB)]]:契约断言作为替代restrict的拼写

(感谢@MCCCS指出最后一个)

除了在其他人的回答中列出的近年来的讨论之外，以下是Bjarne Stroustrup的 c++的设计和发展，其中说明了restrict在20世纪90年代标准化期间被拒绝的原因:

c++委员会自然会赞同任何提高效率的提案，并对该提案进行了一定程度的讨论，但最终决定拒绝它，几乎没有异议。拒绝的主要原因是:

  1. 扩展名不安全。声明指针restrict ed允许编译器假定该指针没有别名。但是，用户不一定知道这一点，编译器也不能保证这一点。由于c++中大量使用指针和引用，因此由此产生的错误可能比Fortran经验所提示的要多。

  2. 扩展的替代方案尚未得到充分的探索。在许多情况下，初始检查重叠以及针对非重叠数组的特殊代码是一种选择。在其他情况下，可以使用直接调用专门的数学库(如BLAS)来调优矢量操作以提高效率。有希望的优化替代方案尚未被探索。例如，对于面向高性能机器的c++编译器来说，对相对较小且程式化的向量和矩阵操作进行全局优化似乎是可行且值得的。

  3. 扩展是特定于体系结构的。高性能数值计算是一个使用专门技术和专门硬件的专门领域。因此，引入特定于非标准体系结构的扩展或pragma可能更合适。如果这种优化的实用性被证明在使用专门机器架构的狭窄社区之外有用，则必须重新评估扩展。

看待这个决定的一种方式是重新确认c++通过一般机制支持抽象，而不是通过特殊目的机制支持专门的应用领域. ......

相关文章：