Здравствуйте, Tilir, Вы писали:

T>>>лучше flex/bison они хоть и хардкорны, но не таят гнилых сюрпризов.
EP>>Если наткнулись на баг в Spirit'е (экспоненциальная сложность там где её быть не должно) — то нужно открыть ticket в их trac'е.
T>Такого рода "баг" это очень часто "споткнулись на неявном неправильном использовании". Свести к простому примеру? Часто не сводится. Выкладывать полностью? Очень много проприетарного кода который не хочется открывать даже примерно.

По моему опыту часто всё локализуется через банальное "разделяй и властвуй" — причём это относится не только к шаблонному мета-программированию.
И только в редких случаях важны какие-то сайд-эффекты влияния под-частей друг на друга (так что при удалении/выключении одной из них исследуемый эффект пропадает).

T>Вот кстати интересно -- а кто что использует для получения "препроцессированных" исходников после всех шаблонных подстановок?

Что конкретно имеется в виду? Для какой цели?
Если для выявления самой долгой instantiation — то тут нужно не раскрытие, а замеры времени.
Если для тестирования — то здесь нужны unit-test'ы, а не результирующие подстановки.
По большому счёту для макросов (или для кодогенерации) результирующие подстановки полезны потому что манипуляция происходит на уровне конкатенации незаконченных текстовых фрагментов кода (которые могут комбинироваться причудливыми способами), в случае же шаблонов картина принципиально иная.
Если же речь идёт не про результирующие подстановки, а про своего рода backtrace воплощений с промежуточными аргументами — то каждый современный компилятор C++ умеет его выводить (при compile error; которую при необходимости можно спровоцировать вручную).
Если же для оценки оптимальности результирующего кода — то тут естественно нужно смотреть в результирующий ASM.

T>Может уже все давно спасены и я один во мраке?

Для отладки и профилирования шаблонного кода создаются разные утилиты, например: Metashell, Templight. Но я пока обхожусь без их помощи.