C ++ 11是否添加了C99限制說明符？ 如果沒有，為什么不呢？

Question

restrict是一個C99功能，它最近得到了很多關注，允許編譯器對指針執行“以前只能進行Fortran”優化。 這也是微軟最近公布的相同關鍵詞，它是C ++ AMP規范的基礎。

該關鍵字實際上是在FCD中嗎？ 如果沒有，是否有特定原因被省略？

Answer 1

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

許多庫函數的描述依賴於C標准庫來獲取這些函數的簽名和語義。 在所有這些情況下，應省略對restrict任何使用。

所以restrict不在C ++ 11中。

Answer 2

一個論點是C需要比C ++更多的restrict ，因為許多操作是使用指向原始類型的指針完成的，因此C代碼比C ++有更多的別名問題。

別名規則說指向不同類型的指針不能別名，因此如果函數的參數具有不同的類類型，則它們不能重疊。

在C ++中，我們還有valarray類，它們應該處理不允許別名的基本類型數組。 不是說它用得太多了......

添加另一種方法來解決一些別名問題，顯然並沒有讓委員會充分興奮。

Answer 3

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

不僅VC ++團隊，而且ISO C ++標准委員會，分別考慮增加對VC ++和ISO C ++的限制。 雖然它是專門為ISO C ++ 11建議的，但它被拒絕了，部分原因是它並不總是很明顯它是如何擴展到C ++代碼的，因為C ++是一種更大的語言，有更多選項，我們希望確保該功能在整個語言。

Answer 4

不要認為它是在C ++ 1x中（遺憾的是時間已經耗盡了0x ......！）但至少msvc和g ++通過__restrict和__restrict__擴展支持它。 （我不使用gcc，我認為這是正確的擴展）。

為了正常使用C ++，我覺得我們還需要有限的引用，而不僅僅是指針，可能與我的問題C ++別名規則一致 。 不確定這些考慮因素是否可能會阻礙......

Answer 5

我會抓住“為什么不呢？”

restrict基本上只是編譯器無法驗證的斷言。 （或者更准確地說，當編譯器可以驗證它時，斷言本身沒有幫助。）這不是C ++委員會喜歡的那種東西。 C ++總是傾向於假設“足夠聰明的編譯器”; 哎呀，看看編譯器趕上之前最瑣碎的C ++庫的糟糕表現。

我還懷疑委員會認為，在存在所有其他C ++特性（引用，右值引用，等等等等）的情況下定義restrict語義將是非平凡的。

因此，指定+“足夠智能的編譯器並不需要它”非常重要= NAK。