[c++][рефакторинг] Проверка параметров конструктора.

Можно посмотреть в сторону Q_ASSERT из состава Qt. Только не все Qt тащить, а определить самостоятельно подобные маркосы.

Первое, что пришло в голову:

Сделать все конструкторы шаблонными, параметр шаблона - булева константа, по умолчанию - false.

Было:

class C
{
  C(X x) { throw_if_wrong(x); }
};

Стало:

class C
{
  template<bool validate = false>
  C(X x) { if(validate) throw_if_wrong(x); }
};

Биндинги придётся переписать, явно указав вызов конструктора с параметром true.

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

Компилировать не пробовал, но на первый взгляд должно проканать :)

Сделай свободные функции для проверки типов. В релизной сборке у них должно быть пустое тело. Вызовы пустых функций компилятор должен удалить.

Он хочет, чтобы при вызове из биндинга проверка все-таки производилась.

Он хочет, чтобы при вызове из биндинга проверка все-таки производилась.

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

А разве из-за этого не придется все конструкторы тащить в хедера?

Все проверки обернуть в макросы типа assert.

А разве из-за этого не придется все конструкторы тащить в хедера?

При желании, можно в сpp-файлах инстанциировать шаблоны. http://www.cplusplus.com/articles/1C75fSEw/

Можно посмотреть в сторону Q_ASSERT из состава Qt. Только не все Qt тащить, а определить самостоятельно подобные маркосы.

Пиздец. Вот и выросло поколение...

Сделай свободные функции для проверки типов. В релизной сборке у них должно быть пустое тело. Вызовы пустых функций компилятор должен удалить.

Примерно к этому пока и склоняюсь. Но их всё равно придётся вызывать в каждом конструкторе и в обёртке для python. Также в данном случае исчезает наследование проверок (автоматический вызов проверок базового класса при создании субкласса). Так что, либо вызывать все проверки явно, либо вместо свободных функций строить иерархию классов для проверки.

При желании можно себя и за локоть укусить. Но в данном конкретном случае шаблоны это совсем-совсем-совсем лишнее... гемора от них будет несоизмеримо больше чем пользы. Говорю как человек, интенсивно скрещивающий плюсы и питон, но у меня просто выбора нету, а у ТСа пока есть;-)

ТС-у - а через что привязка к питону происходит? Можно сделать макрос и навтыкать его там, где нужно.

#ifdef DEBUG
if( !check_arg(arg) ) raise ... ;
#endif

Собираем отладочную версию

g++ ... -DEBUG ...

g++ ...

НО: с одной стороны идея с наследованием проверок хороша. С другой стороны чудес не бывает, если некий субкласс должен проверять все аргументы, а часть и них проверяет его предок, то проверку в предке придется оставить и она пойдет во всех наследников. Для таких случаев самый простой вариант - завести у предка виртуальную ф-ю

#ifdef DEBUG
virtual bool need_check_arg(){ return true; }
#else
virtual bool need_check_arg(){ return false; }
#endif

ЗЫ а Вы уверены в том, что их вообще надо отключать и что тормоза связаны именно с проверками? Т.е. Вы тестили производительность с проверками и без, выяснили что разница получается кардинальной, причем все проверки вносят существенный вклад и отключать надо именно все проверки, а не каких то две-три? Или это Вам просто кажется - «ой у нас проверок много, наверное они тормозят...» ?;-)

ЗЫЗЫ. Очепятка, при сборке отладочной версии ес-но

g++ ... -DDEBUG ...

ЗЫ а Вы уверены в том, что их вообще надо отключать и что тормоза связаны именно с проверками? Т.е. Вы тестили производительность с проверками и без, выяснили что разница получается кардинальной, причем все проверки вносят существенный вклад и отключать надо именно все проверки, а не каких то две-три? Или это Вам просто кажется - «ой у нас проверок много, наверное они тормозят...» ?;-)

Смотрелись результаты под valgrind'ом. К сожалению, часть проверок требует поиска по словарю, что в итоге даёт около 20% от общего времени выполнения функции.

ТС-у - а через что привязка к питону происходит? Можно сделать макрос и навтыкать его там, где нужно.

boost::python

Для таких случаев самый простой вариант - завести у предка виртуальную ф-ю

Всегда думал, что вызывать виртуальные методы из конструктора запрещено. Или есть исключения?

Всегда думал, что вызывать виртуальные методы из конструктора запрещено. Или есть исключения?

Да, туплю. Запрета нету, но виртуальность не работает;-( Тогда надо думать, если юзать наследование фактически Вам нужно реализовать некое подобие механизма вирт функций для включения/выключения проверки.