Какие части стандартной библиотеки С++ 14 могут быть и какие части будут сделаны constexpr?

С новым расслабленным С++ 14 правилами constexpr программирование во время компиляции становится намного более выразительным. Интересно, будет ли обновлена ​​стандартная библиотека, чтобы воспользоваться преимуществами. В частности, std::initializer_list, std::pair, std::tuple, std::complex, std::bitset и std::array кажутся первыми кандидатами, которые будут помечены constexpr оптовой.

Вопросы:

  • какие части стандартной библиотеки будут теперь отмечены constexpr?
  • какие другие могли быть отмечены constexpr?
  • например. почему функции <cmath> и <algorithm> не отмечены constexpr?
  • Есть ли причины обратной совместимости, чтобы не делать этого?

Ответы

Ответ 1

какие части стандартной библиотеки будут теперь отмечены как constexpr?

Из проекта, который я рассмотрел для С++ 14, N3690, до сих пор будет изменено на constexpr (при сравнении со стандартом С++ 11) & dagger;:

  • std::error_category конструктор по умолчанию
  • std::forward
  • std::move
  • std::move_if_noexcept
  • Все сравнения операторов std::pair
  • std::get для std::pair и std::tuple.
  • std::make_tuple
  • Все сравнения операторов std::tuple
  • Все сравнения операторов std::optional
  • Все конструкторы std::optional (за исключением перемещения)
  • operator[] и size для std::bitset и других контейнеров.
  • Все сравнения операторов std::complex

& крестик; Так как я сделал это вручную, вы можете ожидать некоторые ошибки: (

Для другого, возможно, более правильного списка дополнений constexpr вы можете проверить: N3469, N3470 и N3471

какие другие части могут быть отмечены как constexpr?

Большинство материалов, которые могут быть constexpr (std::numeric_limits оценки, конструкторы std::tuple и std::pair и т.д.), уже были отмечены как constexpr в стандарте С++ 11. Была ошибка, в которой std::ratio точки времени и другие компоненты не были отмечены как constexpr, но были исправлены в N3469.

Что-то, что принесет пользу от добавлений constexpr, было бы std::initializer_list, которое на этот раз не получилось (и я не уверен, были ли какие-либо предложения, чтобы разрешить это).

Есть ли причины обратной совместимости, чтобы не делать этого?

Поскольку это расширение, большинство вещей не будет разбито, поскольку старый код все равно будет компилироваться как есть, и теперь ничего плохого не сформировано. Однако добавление constexpr к старым вещам, которые его не имели, может привести к неожиданным результатам, если вы этого не ожидали, например пример здесь (Спасибо TemplateRex)

Ответ 2

На прошлой неделе (23-28 сентября 2013 г.) комитет по стандартизации добавил constexpr к большему количеству процедур в стандартной библиотеке.

  • forward_as_tuple
  • метод operator () всех операторов сравнения/логического/побитового имени. (less, greater, plus, minus, bitwise_and, logical_or, not1 - и все остальное)

@TemplateRex: мы приближаемся к сортировке массивов во время компиляции.

Однако мы также решили проблему LWG 2013, заявив, что разработчики стандартных библиотек НЕ имеют свободы совершать вызовы, которые не определены в стандарте как constexpr как constexpr, поскольку такая разница между реализациями может измениться поведение некоторого кода.