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

E>Ну-ну. Работает и пусть работает. Ты мне еще расскажи, что статическая типизация на 99% устраняет необходимость тестирования приложений. Что после успешной компиляции нужно проверить всего две вещи -- что программа успешно стартует и столь же успешно завершается. Если эти условия выполняются, значит все работает корректно.

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

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

E>Увольте, батенька. Рассказывай эти сказки начинающим программистам, которые кроме окошек в WinForms ничего не программируют.

Кто-там у нас постоянно рассуждал как другие неумеют воспринимать чужое мнение?

VD>>Обясняю последний раз и закроем тему.

E>Не нужно считать окружающих тупее себя. То, что ты излагаешь ниже я и без тебя прекрасно понимаю, благо разные преобразователи исходных текстов писать приходилось.

Ты прочти тсвои сообщения вверх по ветке. Потом поговорим о степени твоего понимания.

E>Я просто хотел понять, что делать в случае, когда я вижу, что некий макрос, производящий compile-time вычисления подставляет мне в код явно не правильную константу. Причем делает это он не всегда, а один раз в некотором месте исходного кода.

Слушай, ты задолбал. Поставь себе Немерле и повозить с ним пару дней. Вопросы уйдут сами собой. Или будут хотя бы более осмысленны.

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

macro BreakMyCacro()
{
    Debug._dbgFlag = true;
}

module Debug
{
  intrnal bool _dbgFlag;
}

Далее в макросе написать нечто вроде:

macro MyCacro()
{
    if (Debug._dbgFlag)
    {
        _dbgFlag = false;
    }
    ...

и поставить точку останова внутрь if-а. Далее остается вписать вызов BreakMyCacro() в нужном месте объектного кода.
3. Воспользоваться макросом выводящим окончательный код пораждаемый макросом и разобраться что в нем не так.
4. Декомпилировать получаемую сборку с помощью Рефлектора и полядеть на получаемый код.

E>То, что нельзя зайти в код макроса из обычной отладки моего кода я и без вас с IT прекрасно понимал.

Да? Тогда к чему столь бесмысленные вопросы? Крышу рвет от метауровенй, что ли? Это бывает.

E>Я не понимал, как войти в отладку кода макроса, когда этот код работает в отдельном параллельном процессе ncc.

Отдельном от чего? От только в нем и работает.

E> Оказалось, что провоцируется отладка процесса компилятора путем подстановки в код макроса специальных провоцирующих отладку инструкций (вроде Assert(false)).

Тебе уже не один человек сказал, что это один из способв. Можно просто поставить точку останова в нужном месте макроса.

Это уже чистейшая клиника. Я устал повторять одно и тоже. Макрос выполняется при компиляции. Точка! Нет никаких параллельных процессов. Процесс один ncc.exe. Порождаемая (объектаная) программа в этот момент еще скопилирована и говорить ней бессмысленно.

E> После этого стало понятно. Напомнило, как некоторые товарищи в C/C++ код вставляли asm { int 3h; } (вроде так).

Нда, маразм крепчал (с). Какие на фиг "asm { int 3h; }"? Где их ставить? В метакоде? Ну, ды в нем можно и просто точку останова поставить. А asm { int 3h; } в прикладном коде будет просто набором AST-веток, то есть данных. Остановиться на этих данных невозможно.

Попробуй поставить asm { int 3h; } где-нибудь внутри макроса С++ или в метакоде на основе шаблонов. Будет смешно.

E>Только для этого способа, как я понимаю, нужно иметь компилируемый исходный код макроса чтобы вставить в него Assert(false) и перекомпилироваться.

Здрасте. Приехали. А что ты собрался отлаживать тогда? Если у тебя нет исходника макроса, то единственное что ты можешь сделать — это зафиксировать его некорректное поведение. Если вспомнить, что метакод — это такой же код как и обычный. То сравнение с отладкой программы без исходников даже аналогией то назвать нельзя. Это одно и тоже.

Нет, ты конечно можешь отлаживаться на уровене ассемблера. Более того, ты даже сможешь декомпилировать код макроса. Но откровенно говря это уже от безвыходности.

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

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

VD>>1. Место не должно влиять на результат, если макрос написан грамотно. Надо стараться делать так, чтобы разные обращения к макросам с одинаковыми параметрами приодили к одинаковому результату. Побочные эффекты иногда конечно полезны, но нужно четко осознавать их опасность. Это ничем не отличается от создания прикладного кода.

E>Прописная истина. Если бы программы писались так просто, необходимости в отладке вообще бы не было.

Не скажи. Ошибки бывют логическими или от недопонимания чужого АПИ. У меня почему-то именно такие и встречаются.

ЗЫ

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