Программистсткие комплексы

[metaclass]

"Отладочные логи и вызовы профилировщика в код вставляют только трусы, неудачники и /забыл слово для тех, кто плохо работает из-за своей тупости/, которые не могут программу написать правильно и эффективно сразу".

Comments

[1ceheart.livejournal.com]

Если вы читали мой коммент внимательно, вы бы заметили, что там написано "для дров". Если в обработчике прерывания будет происходить printf и lzma, вы сильно удивитесь, что это у вас Core2 Duo окошки перерисовывает со скоростью 386.

Простой текстовый лог, конечно, удобней, но не всегда.

[kiryl.livejournal.com]

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

[metaclass.livejournal.com]

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

[kiryl.livejournal.com]

В обработчике прерывания, если всё верно спроектировано верно, выполняется очень мало работы и отладить его не очень сложно.

[1ceheart.livejournal.com]

А логи пишут только трусы и неудачники :)

[blackyblack.livejournal.com]

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

[1ceheart.livejournal.com]

Не самая, но как-то отлаживать нужно. Breakpoint-то туда можно поставить только один раз по понятным причинам, а просто DbgPrint таки вносит коррективы :) Конечно, есть и плугин к kd, и если сказать /debugport=1394, то даже и с DbgPrint можно жить, но тем не менее.

Для слива и анализа бинарных логов они там дают тулзу. Все это довольно надежно работает, как ни странно.

Разумеется, оставлять даже бинарный лог в обработчике прерывания в релизе не сильно кошерно. Хотя некоторые оставляют, а некоторые даже это оговаривают в спецификации, что WMI tracing должен быть в релизе. Там действительно performance overhead очень маленький.