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

$>> TEST.cpp
KP>#include <stdio.h>

KP>void code() {
KP> false && printf("Debug text\n");
KP>}

$>> ICL -Fa test.cpp

KP> PUBLIC ?code@@YAXXZ
KP>?code@@YAXXZ PROC NEAR
KP>$B1$1: ; Preds $B1$0
KP> ret ;5.1

KP>И чго тут линкер увидет ? вызов printf ?

Глупый ответ. Компилятор не обязан это делать, понимаешь, не обязан. Тот факт, что Intel это выкинул, отнюдь не гарантирует того, что все другие компиляторы поступят так же. Нету здесь никаких гарантий, и соответсвенно, не на что надеяться (если, конечно пишется программа ВООБЩЕ, а не программа для конкретного компилятора с конкретными ключами оптимизации).

Ну и потом:

extern int my_variable;

void code()
{
 . . .
 if(0)
 {
    . . .черта лысого и сбоку бантик
    my_function(&my_variable);
 }
 . . .
}

Здесь я сам не знаю, как правильно поступить. С одной стороны, можно выкинуть все нафиг. В другой — я ожидаю, что модуль, в котором определена my_variable будет прилинкован, а для этого надо оставить данный код. И не надо говорить, что если не используешь, то и не надо. Прилинковать бывает надо, особенно в случае полиморфных классов со сложным наследованием.
В этом, кстати, есть еще одна опасность. Возьмем фабрики классов, реализованные по типу MFC, ну там, макросы типа DECLARE_DYNAMIC (или как они там — не помню уже). Так вот, в DEBUG все работает, в RELEASE — падает, потому что компилятор выкинул обращение к классу, а линкер его не прилинковал. В результате получаем null-pointer VMT. В общем, данный подход чреват примерно теми же последствиями, что и ASSERT(a = fgets(buf, 100, fd)), но только в гораздо более редких и гораздо более трудноуловимых случаях.