Re[11]: Метапрограммирование в примерах
От: jazzer Россия Skype: enerjazzer
Дата: 15.05.15 05:23
Оценка: 8 (1)
Здравствуйте, Tilir, Вы писали:

T>На уровне: "сколько раз раскрылся вот этот вот шаблон и с какими параметрами".


Если речь о GCC, то есть флажок -fdump-class-hierarchy
Например, для файла
#include <iostream>
template<class T> struct F {
  static const int value = T::value * F< boost::mpl::int_<T::value-1> >::value;
};
template<> struct F< boost::mpl::int_<0> > {
  static const int value = 1;
};

int main() {
  std::cout << F<boost::mpl::int_<10>>::value << std::endl;
}

получается вот такой вывод:
> grep '^Class F<' test.cpp.002t.class
Class F<mpl_::int_<0> >
Class F<mpl_::int_<10> >
Class F<mpl_::int_<9> >
Class F<mpl_::int_<8> >
Class F<mpl_::int_<7> >
Class F<mpl_::int_<6> >
Class F<mpl_::int_<5> >
Class F<mpl_::int_<4> >
Class F<mpl_::int_<3> >
Class F<mpl_::int_<2> >
Class F<mpl_::int_<1> >
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[11]: Метапрограммирование в примерах
От: Evgeny.Panasyuk Россия  
Дата: 15.05.15 06:02
Оценка:
Здравствуйте, Tilir, Вы писали:

EP>>Что конкретно имеется в виду? Для какой цели?

T>Посмотреть на плюсовый код после всех шаблонных подстановок. На уровне: "сколько раз раскрылся вот этот вот шаблон и с какими параметрами".

Достаточно спровоцировать warning внутри шаблона — и компилятор выдаст backtrace воплощений шаблонов, со всеми аргументами. Правда нужно учитывать что воплощения могут мемоизироваться, и повторного вывода не будет.

T>Цели в основном: оценка оверхеда по размеру кода,


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

T>поиск узких мест по времени компиляции.


Само по себе раскрытие здесь не сильно поможет. Нужно либо делать ручное "разделяй и властвуй", либо делать профилирование а-ля Templight.

EP>>Если же для оценки оптимальности результирующего кода — то тут естественно нужно смотреть в результирующий ASM.

T>Ассемблер после оптимизирующего компилятора с LTO это мелко рубленная каша, лучше уж IR на начальных фазах.

Если на начальных фазах — то значит не все оптимизации применены, для оценки оптимальности это как-то не айс. А при просмотре ASM обычно есть представление о том что там примерно должно быть, или хотя бы о том чего там быть точно не должно.
Отредактировано 15.05.2015 6:08 Evgeny.Panasyuk . Предыдущая версия .
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.