Добавляет ли C++11 спецификатор ограничения C99? Если нет, то почему нет?
restrict - это особенность C99, которая в последнее время привлекает к себе большое внимание, позволяя компилятору выполнять оптимизацию указателей "только для фортрана". Это также то же самое ключевое слово, которое Microsoft недавно объявила в качестве основы спецификации C++AMP.
Это ключевое слово на самом деле в FCD? Если нет, есть ли конкретная причина, по которой он был опущен?
5 ответов
Один аргумент в том, что C нуждается restrict больше, чем C++, потому что многие операции выполняются с указателями на примитивные типы, и поэтому в C-коде больше проблем с наложением, чем в C++.
Правила псевдонимов говорят, что указатели на разные типы не могут иметь псевдонимы, поэтому, если параметры функции относятся к разным типам классов, они просто не могут перекрываться.
В C++ у нас также есть valarray семейство классов, которые должны обрабатывать массивы примитивных типов, которым не разрешен псевдоним. Не то, чтобы это использовалось много...
Добавление еще одного способа решения некоторых проблем с псевдонимами, очевидно, не достаточно взволновало комитет.
Единственное упоминание о restrict в C++11 FDIS находится на §17.2 [library.c]:
Описания многих библиотечных функций основаны на стандартной библиотеке C для сигнатур и семантики этих функций. Во всех таких случаях любое использование
restrictквалификатор должен быть опущен.
Так restrict не в C++11.
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++, прежде чем компиляторы догонят.
Я также подозреваю, что комитет счел, что определение restrict семантика именно при наличии всех других возможностей C++ (ссылки, ссылки на значения, бла-бла-бла) была бы нетривиальной.
Таким образом, нетривиально указать + "достаточно умному компилятору это не нужно" = NAK.