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

Question

restrict - это функция C99, которая в последнее время привлекает к себе большое внимание, позволяя компилятору выполнять оптимизацию указателей «только для фортрана». Это также то же самое ключевое слово, которое Microsoft недавно объявила в качестве основы спецификации C ++ AMP.

Это ключевое слово на самом деле в FCD? Если нет, то есть ли конкретная причина, по которой он был опущен?

Answer 1

Единственное упоминание о restrict в FDIS C ++ 11 - в разделе 17.2 [library.c]:

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

Значит, restrict отсутствует в C ++ 11.

Answer 2

Одним из аргументов является то, что C требует restrict больше, чем C ++, потому что многие операции выполняются с указателями на примитивные типы, и, следовательно, код 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 ++, прежде чем компиляторы догонят.

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

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