Комментарии 8
На мой взгляд, в данном случае такое решение — overkill, проще было бы руками вписать ничего не делающие clear и buffer в варианты initializator, где этих функций нету. Если уж совсем не хочется дублировать код, то сделать для initializator базовый класс, который реализует пустые функции (не надо никакой виртуальности), а в тех initializator, где нужно, просто переопределить их.
Ещё, на мой взгляд, вместо такого:
Ну и напоследок, у вас в классе Logger удален оператор копирования, но не удален конструктор копирования.
Ещё, на мой взгляд, вместо такого:
template<class LogType>
class initializator{};
лучше написать код, который выдает ошибку, если такой шаблон инстанциируется. Потому что вкупе с вашим решением для clear и buffer код типа Logger<int>::buffer() прекрасно компилируется. А может лучше вообще убрать такой шаблон, который используется только для своей полной специализации, и написать 3 отдельных класса?Ну и напоследок, у вас в классе Logger удален оператор копирования, но не удален конструктор копирования.
+2
Спасибо, именно такого конструктивного комментария я ждал, а не просто минусов.
На самом деле, ошибка компиляции будет при «неопределенном» initializator из-за вызова do_log, но ввы правы, лучше было бы, наверное оставить так
Про переопределение мысль интересная, но опять же каждый раз это наследование должно прописываться при определении инициализатора.
А вот отказаться от initializator (извините за название, не я придумывал) — это да, теги здесь излишни.
Merci, что обратили внимание.
На самом деле, я убрал и оператор копирования, поскольку подумал, что если спрятать instance, то не должно быть ситуаций, когда им попытаются воспользоваться, ровно как и конструктором копирования.
На самом деле, ошибка компиляции будет при «неопределенном» initializator из-за вызова do_log, но ввы правы, лучше было бы, наверное оставить так
template<class LogType>
class initializator;
Про переопределение мысль интересная, но опять же каждый раз это наследование должно прописываться при определении инициализатора.
А вот отказаться от initializator (извините за название, не я придумывал) — это да, теги здесь излишни.
Merci, что обратили внимание.
На самом деле, я убрал и оператор копирования, поскольку подумал, что если спрятать instance, то не должно быть ситуаций, когда им попытаются воспользоваться, ровно как и конструктором копирования.
+1
Ух ты, какой элегантный способ, я, честно говоря, думал про какой-нибудь костыль типа:template<class LogType> class initializator;
template<typename T>
struct always_false : public std::false_type {
};
template<class LogType>
class initializator {
static_assert(always_false<initializator>::value, "Some error message");
};
не должно быть ситуаций, когда им попытаются воспользоваться, ровно как и конструктором копированияВ теории можно воспользоваться внутри функций-членов Logger.
+1
Да, и еще скажу, в попытках оправдаться, то мне показалась заманчивой именно сама возможность проверки наличия функции в классе.
+1
Если уж баловаться с шаблонами, надо было делать не теги-пустышки, а полноценные policy. Внутрь них и можно (и даже нужно) было упрятать инициализацию вместо того, чтобы громоздить «initializator» со специализациями.
0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Logger с функциями-членами, которых нет