C++11是否添加了C99限制说明符?如果没有，为什么不呢

Does C++11 add the C99 restrict specifier? If not, why not?

本文关键字：如果没有为什么不说明符添加是否 C99 C++11 更新时间：2023-10-16

restrict是C99的一个功能，最近它通过允许编译器对指针执行"以前只使用fortran"的优化而备受关注。这也是微软最近宣布的作为C++AMP规范基础的同一关键词。

这个关键字真的在FCD中吗？如果没有，是否有具体的原因被省略？

C++11 FDIS中唯一提到的restrict是§17.2[库.c]：

许多库函数的描述依赖于用于签名和语义的C标准库这些功能。在所有此类情况下，应省略restrict质量仪的任何使用。

所以restrict不在C++11中。

一个参数是C比C++更需要restrict，因为许多操作都是用指向基元类型的指针来完成的，因此C代码比C++有更多的混叠问题。

别名规则规定，指向不同类型的指针不能别名，因此，如果函数的参数属于不同的类类型，它们就不能重叠。

在C++中，我们还有valarray类家族，它们应该处理不允许别名的基元类型的数组。并不是说它用得太多。。。

添加另一种方法来解决一些混叠问题，显然并没有让委员会足够兴奋。

http://herbsutter.com/2012/05/03/reader-qa-what-about-vc-and-c99/

不仅是VC++团队，ISO C++标准委员会也考虑分别对VC++和ISO C++添加限制。尽管它是专门为ISO C++11提出的，但它被拒绝了，部分原因是它如何扩展到C++代码并不总是显而易见的，因为C++是一种更大的语言，有更多的选项，我们希望确保该功能在整个语言中正确工作。

不要认为它在C++1x中（不幸的是，0x…！的时间已经用完了），但至少msvc和g++通过__restrict和__restrict__扩展支持它。（我不怎么使用gcc，我认为这是正确的扩展）。

为了用C++正确地使用，我觉得我们还需要限制引用，而不仅仅是指针，也许就像我的问题C++别名规则一样。不确定这些考虑因素是否会阻碍事情的发展。。。

我会尝试一下"为什么不呢？"

restrict基本上只是编译器无法验证的断言。（或者更准确地说，当编译器可以验证它时，断言本身没有帮助。）这不是C++委员会会喜欢的那种事情。C++一直倾向于假设"足够聪明的编译器"；见鬼，在编译器赶上之前，看看最琐碎的C++库的糟糕性能。

我还怀疑委员会认为，在存在所有其他C++特性（引用、右值引用等等）的情况下准确定义restrict语义是不平凡的。

因此，指定+"一个足够智能的编译器不需要它"=NAK并不重要。