И, кроме примера с Пи, как он будет работать с неконстантными переменными?
В настоящее время создается впечатление, что переменные создаются отдельно для типа. т.е. вы можете присвоить 10 n<int>
, и это будет отличаться от определения шаблона.
template<typename T>
T n = T(5);
int main()
{
n<int> = 10;
std::cout << n<int> << " "; // 10
std::cout << n<double> << " "; // 5
}
Если декларация const
, она доступна только для чтения. Если это constexpr
, как и все объявления constexpr
, он не имеет особого смысла за пределами constexpr
(рессий).
Кроме того, мы можем получить эту функцию, просто заключив переменную в шаблонную структуру или класс, как это сочетается с преобразованием типов?
Это должно быть простое предложение. Я не могу понять, как это существенно влияет на преобразование типов. Как я уже сказал, тип переменной - это тип, с которым вы создали экземпляр шаблона. т.е. decltype(n<int>)
- это целое число. decltype((double)n<int>)
- двойной и так далее.
Любой пример использования, чтобы понять, как максимально использовать такую функцию и какова ее цель?
N3651 дает краткое обоснование.
Увы, существующие правила C ++ не позволяют объявить переменную в объявлении шаблона. Есть хорошо известные обходные пути для этой проблемы:
• использовать статические члены данных constexpr шаблонов классов
• использовать шаблоны функций constexpr, возвращающие желаемые значения
Эти обходные пути известны десятилетиями и хорошо задокументированы. Стандартные классы, такие как std :: numeric_limits, являются типичными примерами. Хотя эти обходные пути не идеальны, их недостатки в некоторой степени были терпимыми, потому что в эпоху C ++ 03 только простые встроенные константы типов пользовались неограниченной прямой и эффективной поддержкой во время компиляции. Все это изменилось с принятием переменных constexpr в C ++ 11, которые расширили прямую и эффективную поддержку констант определяемых пользователем типов. Теперь программисты делают константы (типов классов) все более и более очевидными в программах. Так что растут путаница и разочарование, связанные с обходными путями.
...
Основные проблемы со «статическим элементом данных»:
• они требуют «повторяющихся» объявлений: один раз внутри шаблона класса, один раз вне шаблона класса, чтобы обеспечить «реальное» определение в случае использования констант odr.
• программисты одновременно разочарованы и сбиты с толку необходимостью предоставить дважды одно и то же объявление. Напротив, "обычные" объявления констант не нуждаются в повторяющихся объявлениях.
...
Хорошо известными примерами в этой категории, вероятно, являются статические функции-члены numeric_limits или функции, такие как boost::constants::pi<T>()
и т. Д. Шаблоны функций Constexpr не страдают от проблемы «повторяющихся объявлений», которая есть у статических элементов данных; кроме того, они обеспечивают функциональную абстракцию. Однако они заставляют программиста заранее выбрать на сайте определения, как константы должны быть доставлены: либо с помощью ссылки на константу, либо с помощью простого не ссылочного типа. Если доставляется по ссылке на константу, то константы должны систематически размещаться в статической памяти; если по не ссылочному типу, то необходимо копировать константы. Копирование не является проблемой для встроенных типов, но это демонстрация возможностей для определяемых пользователем типов с семантикой значений, которая не является просто оболочкой для крошечных встроенных типов (например, матричных, целочисленных, bigfloat и т. Д.) Напротив, " обычные "const (expr) переменные" не страдают от этой проблемы. Предоставляется простое определение, и решение о том, действительно ли нужно размещать константы в хранилище, зависит только от использования, а не от определения.
person
Community
schedule
16.01.2014