У меня есть проблемка. Моя прога вылеает, и не понятно где.
Как в builder'е узнать в какой функции случается это самое плохое и откуда она вызывалась, как ,скажем, в Visual C. Чувствую это где-то есть, а найти не могу.

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

N>У меня есть проблемка. Моя прога вылеает, и не понятно где.
N>Как в builder'е узнать в какой функции случается это самое плохое и откуда она вызывалась, как ,скажем, в Visual C. Чувствую это где-то есть, а найти не могу.

1) Включить debug info?
2) Tools -> Debugger Options -> OS Exceptions -> Handled by -> Debugger. Там же можно поставить stop on delphi exceptions.

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

V>1) Включить debug info?
V>2) Tools -> Debugger Options -> OS Exceptions -> Handled by -> Debugger. Там же можно поставить stop on delphi exceptions.

Еще хорошая штука CodeGuard позволяет отловить трудные ошибки с указателями, лики и т.п.

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

N>У меня есть проблемка. Моя прога вылеает, и не понятно где.
N>Как в builder'е узнать в какой функции случается это самое плохое и откуда она вызывалась, как ,скажем, в Visual C. Чувствую это где-то есть, а найти не могу.

Первое правило отладки: написал кусок кода — проверь его под отладчиком.

Второе правило отладки — выделение минимального объема кода, который будет находится "под подозрением" у отладчика. То есть — локализация потенциально проблемного кода. Обычно осуществляется комментированием кусков кода и прогоном под отладчиком до тех пор, пока после комментирования очередного куска кода проблема не исчезнет.

Третье правило отладки — не забывать о первых двух

Четвертое правило отладки — приучить себя писать (как пример)

if(some_condition)
    some_function();

а не

if(some_condition) some_function();

Помогает при пошаговой трассировке (в Билдере это F8).


Пятое правило отладки — после внесения _любой_ дополнительной функциональности проверить _все_ куски кода, которые/от которых зависит новая функциональность на предмет штатной работы.

Вот, что смог

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

F>Первое правило отладки: написал кусок кода — проверь его под отладчиком.
...
Да дело не в том! Я, конечно, стараюсь соблюдать подобный свод правил.(вплоть до резервного копирование перед каждым нововведением)
Но бывают времена, когда у тебя времени на что-либо нет, писать нужно быстро и правильно, но как всё работает — ты приблизительно знаешь. Со скоростью печатной машинки ты делаешь это, а отлаживать в условиях проекта возможность нет. А теперь вся эта фигня выкидывается где-то. Кода — много, очего много!!! Весь не проверишь. А небось где-нибудь просто i c j перепутал.
А мне всего нужно узнать — как настроить C++Builder 6, чтоб он после выдачи ошибки говорил, в какой функции это произошло и кто её вызвал. Ну просто не может быть, чтоб этого не было!

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

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

F>>Первое правило отладки: написал кусок кода — проверь его под отладчиком.
N>...
N>Да дело не в том! Я, конечно, стараюсь соблюдать подобный свод правил.(вплоть до резервного копирование перед каждым нововведением)

[]

Значит, вы все-же не соблюли одно из правил... Чтобы не путать i c j, неплохо было бы пользоваться отладочными макросами, вроде ASSERT(условие). И тогда, когда это условие будет нарушено, получите красивый debug assertion при прогоне проекта... А так вот, навскидку, в большом коде найти то самое глючное место — это, знаете ли, бывает большим геморроем (ну да вы точно знаете )...

В вашем случае других вариантов, кроме как планомерная работа по нахождению проблемного участка кода, я не вижу... ИМХО сами виноваты в том, что не потрудились в свое время внести необходимую отладочную информацию...

З.Ы. Кстати, описанная вами проблема оочень напоминает проблему плохого дизайна проекта...