Есть ли причина сделать параметр шаблона шаблона невариативным?

Если я ожидаю, что параметр шаблона шаблона будет иметь один аргумент, я мог бы объявить его следующим образом:

template<template<typename> class T>
struct S {
    T<int> t_;
    //other code here
}

однако, если позже я захочу предоставить параметр шаблона шаблона, который принимает два аргумента, где второй имеет значение по умолчанию (например, std::vector), T<int> t_; все равно будет работать, но шаблон не будет соответствовать template<typename> class T. Я мог бы исправить это, превратив template<typename> class T в вариативный шаблон шаблона template<typename...> class T. Теперь мой код более гибкий.

Должен ли я в будущем сделать все параметры моего шаблона вариативными? Есть ли какая-то причина, по которой я не должен этого делать (при условии, что поддержка С++ 11 уже требуется для моего кода по другим причинам)?


c++ templates c++11 variadic-templates template-templates
person odinthenerd    schedule 10.01.2014    source источник

Ответы (2)


arrow_upward
5
arrow_downward

Во-первых, документация. Если параметр является вариативным, пользователю теперь нужно проверить какой-либо другой источник, чтобы узнать, что ему действительно нужно что-то, что будет принимать один параметр шаблона.

Во-вторых, ранняя проверка. Если вы случайно передадите два аргумента T в S, компилятор не сообщит вам, является ли он вариативным, пока пользователь не попытается его использовать.

В-третьих, сообщения об ошибках. Если пользователь передает шаблон, который на самом деле нуждается в двух параметрах, в вариационной версии компилятор выдаст ему сообщение об ошибке в строке, где S создает экземпляр T, со всеми обратными трассировками между ними. В исправленной версии он получает ошибку, когда создает экземпляр S.

В-четвертых, в этом нет необходимости, потому что псевдонимы шаблонов тоже могут решить эту проблему.

S<vector> s; // doesn't work
// but this does:
template <typename T> using vector1 = vector<T>;
S<vector1> s;

Итак, мой вывод: не делайте вещи вариативными. На самом деле вы не получаете гибкости, вы просто немного уменьшаете объем кода, который пользователь должен написать, за счет ухудшения читабельности.

person Sebastian Redl    schedule 10.01.2014
comment
Нет, это то, что я имею в виду. Здесь есть два вида ошибок. Во-первых, пользователь передает неправильный шаблон, о чем я расскажу в третьем пункте. Во-вторых, вы, автор S, ошиблись в написании шаблона, о чем и идет речь во втором пункте. - person Sebastian Redl; 10.01.2014

arrow_upward
2
arrow_downward

Если вы уже знаете, что он вам понадобится с высокой вероятностью, вы должны его добавить. В противном случае вам это не понадобится (YAGNI), так что это добавит больше вещей для обслуживания. Это похоже на решение иметь параметр шаблона в первую очередь. Особенно в среде типа TDD вы будете проводить рефакторинг только тогда, когда возникнет необходимость, а не делать преждевременную абстракцию.

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

Роберт К. Мартин, стр. 132, Agile-принципы, шаблоны и практика в C#

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

person TemplateRex    schedule 10.01.2014
comment
Я бы согласился, если бы их добавление было большой работой, однако добавление трех точек едва ли упоминается. Суть моего вопроса в том, какие накладные расходы на обслуживание я могу вызвать? Я не могу придумать ни одного, но я ошибался достаточно часто, чтобы знать, чтобы спросить сообщество. - person odinthenerd; 10.01.2014
comment
@PorkyBrain уверен, что добавление ... — это простая часть. но теперь вы также должны задокументировать, что вы будете делать с этими дополнительно переданными параметрами, есть ли у них аргументы по умолчанию, есть ли какие-либо другие ограничения на них и т. д. Это просто добавляет больше поддержки вашему коду. - person TemplateRex; 10.01.2014