Добавляет ли С++ 11 спецификатор ограничения C99? Если нет, почему бы и нет?

Ответ 1

Один аргумент состоит в том, что C нуждается в restrict больше, чем С++, потому что многие операции выполняются с указателями на примитивные типы, поэтому C-код имеет больше проблем с псевдонимом, чем С++.

Правила псевдонимов говорят, что указатели на разные типы не могут быть псевдонимом, поэтому, если параметры для функции имеют разные типы классов, они просто не могут перекрываться.

В С++ мы также имеем семейство классов valarray, которые должны обрабатывать массивы примитивных типов, которые не допускаются к псевдониму. Не то, чтобы он использовался много...

Добавление еще одного способа решения некоторых проблем с псевдонимом, очевидно, недостаточно возбуждало комитет.

Ответ 2

Единственное упоминание о restrict в С++ 11 FDIS находится в разделе & sect; 17.2 [library.c]:

Описание многих функций библиотеки зависит от стандартной библиотеки C для подписей и семантики этих функций. Во всех таких случаях любое использование квалификатора restrict должно быть опущено.

Итак, restrict не находится в С++ 11.

Ответ 3

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

Не только команда VС++, но и комитет стандартов ISO С++, считали, что добавление ограничивает VС++ и ISO С++, соответственно. Хотя это было специально предложено для ISO С++ 11, оно было отвергнуто, отчасти потому, что не всегда очевидно, как он распространяется на С++-код, потому что С++ - это более крупный язык с большим количеством опций, и мы хотели бы удостовериться, что функция работает правильно весь язык.

Ответ 4

Не думайте, что это в С++ 1x (к сожалению, время уже закончилось для 0x...!), но по крайней мере msvc и g++ поддерживают его через расширения __restrict и __restrict__. (Я не использую gcc много, я думаю, что правильное расширение).

Чтобы правильно работать с С++, я чувствую, что нам также понадобятся ограниченные ссылки, а не только указатели, возможно, по строкам моего вопроса правила псевдонимов С++. Не уверен, что некоторые из этих соображений могут удержать вещи...

Ответ 5

Я взломаю "почему бы и нет?"

restrict - это просто утверждение, которое компилятор не может проверить. (Или, точнее, когда компилятор может это проверить, само утверждение не полезно). Это просто не то, что нравится комитету С++. С++ всегда склонялся к "достаточно умным компиляторам"; черт возьми, посмотрите на отвратительную производительность самых тривиальных библиотек С++ до того, как компиляторы догнали.

Я также подозреваю, что комитет считает, что определение семантики restrict именно в присутствии всех других функций С++ (ссылки, ссылки rvalue, blah blah blah) было бы нетривиальным.

Итак, нетривиально указать + "достаточно интеллектуальный компилятор не нужен" = NAK.