Как Вы отлаживаете в большой степени шаблонный код в C++?

Можно попытаться использовать более новый компилятор. Если Вы используете Visual C++ 6.0, переключаетесь на 9,0, и Вы будете видеть огромный переход в любезности ошибок компилятора.

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

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

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

При создании чего-то сложным на языке метапрограммирования, я использую макрос BOOST_MPL_ASSERT многократно, проверяя результаты каждого шага метавыполнения. Повышение. Библиотека MPL очень полезна в этом отношении. Я предлагаю, чтобы Вы использовали как можно больше кода оттуда, потому что вероятно, что это не будет содержать ошибки.

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

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

, Но самая важная вещь должен попытаться не использовать метапрограммирование везде . Это сложно, так используйте его только когда Вы действительно потребность он.

Это должно помочь Вам, я думаю.

http://www.bdsoft.com/tools/stlfilt.html

я не использовал его сам; но, это могло бы помочь Вам. Я могу также сказать Вам что, поскольку Вы получаете больше опыта с шаблонами и метапрограммами, Вы привыкнете к сообщениям об ошибках. Они могут быть немного жесткими для чтения иногда; но, существует логика к их безумию. Просто сделайте свой терминал столь большим, как Вы можете и пытаться перевести то, что он говорит в Вашей голове, поскольку Вы читаете его.

Какой компилятор Вы используете? VC8 и 9 на самом деле довольно достойны при выводе читаемых сообщений об ошибках. Все еще требуется немного терпения пройти, но это может быть сделано, и они по существу показывают время компиляции, эквивалентное из стека вызовов. Запуск внизу, которые обрабатывают инстанцирование по шаблону, вызвал ошибку, и каковы были аргументы шаблона? Затем выровняйте, показывает шаблон, от которого это инстанцировали и так далее, полностью до верхнего уровня. Конечно, это только видимо на "выходной" вкладке, не "ошибочной" той, которую она обычно показывает после неудавшейся компиляции.

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

Это - боль, но это может быть сделано, и это требует не чему иному как терпению и готовности прочитать сообщения об ошибках. :)

кроме того, свободное использование static_assert (или BOOST_STATIC_ASSERT) может помочь много путем обеспечения проверок работоспособности

Вы привыкаете к нему с течением времени, и к сожалению если Вы планируете использование C++, Вы имеете к. Поскольку, некоторые библиотеки как VC9 имеют хорошие сообщения об ошибках, но как только Вы перемещаетесь, чтобы сказать, что GCC, или некоторого другого компилятора, сообщений не стало. И даже VC9 не поможет Вам очень, когда у Вас будут ошибки из некоторой библиотеки, записанной кем-то еще или Вами во время ночного, даже некоторые библиотеки Boost не являются настолько дружественными. Просто, потому что не каждый автор позаботился ясно давать понять вещи, когда ошибка происходит, и это еще более распространено с новыми библиотеками (которые имеют тенденцию иметь большинство ошибок и меньше справки).

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

Используя инструменты выручит Вас в начале, но причинит Вам боль на длительном периоде. И так как проблема свойственна из C++, не уходить любого дня скоро. И эти стены ошибок, вероятно, будут с нами, пока C++ больше не будет использоваться. Таким образом, инструменты просто получат первый опыт при необходимости в них для выживания. Если Вы планирование отъезда C++ скоро, то не стесняйтесь использовать их. В наше время я могу обычно понимать те сообщения об ошибках с 400 строками в одном взгляде, таким образом, они совершенно прозрачны к моим глазам, но это не благодаря никаким инструментам.

Как со всем, особенно C++, это берет опыт и обучение.

Поскольку ответы уже иллюстрируют, существует в основном 2 типа трудностей в коде шаблона: 1. то, чтобы заставлять это скомпилировать, и найти причину для ошибок компилятора 2. получение его действительно делает правильную вещь во время времени выполнения

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

, Если Вы затем следуете советам от других ответов, особенно тот о compile_time утверждает, будет легче найти источник проблемы.

Для отладки часто это помогает просто остановить метапрограмму в какой-то момент и показать тип, который является результатом некоторого вычисления типа. Это может быть достигнуто как это:

template <class T>
struct mp_debug : T::MP_DEBUG_FORCE_COMPILE_FAILURE {};

using Foo = int; // type to be inspected

// usage at namespace scope
template struct mp_debug<Foo>;

// usage at function scope
int main() {
  mp_debug<Foo>{};
}

Это заставляет компилятор печатать ошибку времени компиляции, которая показывает оцененный аргумент типа mp_debug.