C++11 是否添加了 C99 限制说明符？如果没有，为什么不呢？
restrict 是一项 C99 功能，最近由于允许编译器对指针执行“以前仅适用于 Fortran”的优化而受到广泛关注。这也是 Microsoft 最近宣布作为 C++AMP 规范基础的相同关键字。
该关键字实际上在 FCD 中吗？如果没有，是否有被省略的具体原因？
restrict is a C99 feature which is getting a lot of attention lately by allowing the compiler to perform "previously-fortran-only" optimizations to pointers. It's also the same keyword announced by Microsoft recently to be the underpinnings of the C++AMP specification.
Is that keyword actually in the FCD? If not, is there a specific reason it was omitted?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
C++11 FDIS 中唯一提及
restrict的是第 17.2 节 [library.c]：所以
restrict不在 C++11 中。The only mention of
restrictin the C++11 FDIS is on §17.2 [library.c]:So
restrictis not in C++11.一种说法是，C 比 C++ 更需要
限制，因为许多操作是通过指向基本类型的指针完成的，因此 C 代码比 C++ 存在更多别名问题。别名规则规定，指向不同类型的指针不能别名，因此如果函数的参数属于不同的类类型，它们就不能重叠。
在 C++ 中，我们还有 valarray 类系列，它们应该处理不允许别名的基本类型数组。并不是说它被广泛使用...
添加另一种方法来解决一些别名问题，显然没有让委员会足够兴奋。
One argument is that C needs
restrictmore than C++, because many operations are done with pointers to primitive types and therefore C code has more aliasing problems than C++.The aliasing rules say that pointers to different types cannot alias, so if the parameters to a function are of different class types they just cannot overlap.
In C++ we also have the
valarrayfamily of classes that are supposed to handle arrays of primitive types that are not allowed to alias. Not that it is used much...Adding yet another way to resolve some aliasing problems, obviously didn't excite the committee enough.
http://herbsutter.com/2012/ 05/03/reader-qa-what-about-vc-and-c99/
http://herbsutter.com/2012/05/03/reader-qa-what-about-vc-and-c99/
不要认为它是在 C++1x 中（不幸的是 0x 的时间已经用完了......！），但至少 msvc 和 g++ 通过 __restrict 和 __restrict__ 支持它扩展。 （我不太使用 gcc，我认为这是正确的扩展）。
为了正确地使用 C++，我觉得我们还需要受限引用，而不仅仅是指针，也许按照我的问题C++ 别名规则。不确定其中一些考虑因素是否会阻碍事情的发展......
Don't think it's in C++1x (unfortunately time has long run out for 0x...!) but at least msvc and g++ support it through
__restrictand__restrict__extensions. (I don't use gcc much, I think that's the correct extension).To work properly with C++ I feel that we would also need restricted references, not just pointers, maybe along the lines of my question C++ aliasing rules. Not sure if some of these considerations might be holding things up...
我会尝试“为什么不呢？”
restrict基本上只是编译器无法验证的断言。 （或者更准确地说，当编译器可以验证它时，断言本身没有帮助。）这不是 C++ 委员会喜欢的事情。 C++ 一直倾向于假设“足够智能的编译器”；哎呀，看看在编译器赶上之前最琐碎的 C++ 库的可怕性能。我还怀疑委员会认为在所有其他 C++ 功能（引用、右值引用、等等）存在的情况下精确定义限制语义将是不平凡的。
因此，指定 +“足够智能的编译器不需要它”= NAK 并不简单。
I will take a crack at "why not?"
restrictis basically just an assertion that the compiler cannot verify. (Or more precisely, when the compiler can verify it, the assertion itself is not helpful.) This is just not the sort of thing that the C++ committee is going to like. C++ has always tended to assume "sufficiently smart compilers"; heck, look at the hideous performance of the most trivial C++ libraries before the compilers caught up.I also suspect the committee felt that defining
restrictsemantics precisely in the presence of all the other C++ features (references, rvalue references, blah blah blah) would be non-trivial.So, non-trivial to specify + "a sufficiently smart compiler doesn't need it" = NAK.