Есть программа, написанная на Си, рабочая.
Для отладки программы использовал 16х2-дисплей. Т.к. программа написана, необходимо убрать этот дисплей.
Чтобы это можно было сделать быстро, везде, где он используется, писал так:



и в самом начале листинга соотвественно



где можно быстро включать-выключать дисплей.

Суть вот в чем - ни разу я его не отключал (да и зачем было?), программа написана, пришло время поставить вместо единицы нолик, что и было сделано. И тут программа перестала работать.




Шерстя по ассемблерному коду, увидел, что перед while(1) появился такой код:



самого while() нету, да собственно и не нужен, т.к. RJMP PC-0x0003 зацикливает программу на месте между nop'ами.

Почему такое происходит, и как от этого избавиться?

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

Компилятор совершенно прав! Он видит, что переменная RecipientComplete определена нулем и нигде более не изменяет своего значения. После чего понимает, что тело if(RecipientComplete == 1){} никогда работать не будет. А раз так, то этот if незачем и компилировать. После чего оказывается, что while(1) крутит только пару nop'ов. Вот он эту пару nop'ов вам и запрограммировал.

А если RecipientComplete может изменять свое значение где-то еще, то в таком случае ее положено объявлять как volatile, в чем меня опередил Палыч.

Гениально
Всем спасибо, помогло.

Чтобы это сделать быстро - есть условная компиляция



Отладочный вариант:



Обычный без отладочных сообщений:



иначе LCD вам не нужен больше а код ненужный так и останется или его вручную выковыривать нужно. К тому же если завтра вам захочется отладку выводить через UART - достаточно будет поменять #define DBG(s) uart_puts(s) или любой другой вариант в зависимости от потребности.

Да конечно. Неиспользуемый код ни один современный компилятор выкидывать не умеет. Dead code elimination - сказки для красноглазиков.

Кстати, конструкция

во многих случаях нагляднее, чем

Особенно, если подсветки синтаксиса нет.

А это вы видимо проигнорировали



Например послезавтра считаем все неинициализированные переменные ошибкой и нужно локализовать их



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

Я отвечал ровно на то, что процитировал. Вчитайтесь в свои собственные слова и учитесь отвечать за них.

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

Вообще-то основной смысл был тут



а неточности - были, да. Вы таки рекомендуете делать так ?
if (LCD)
lcd_puts();

Угу, переходим от неточностей к необоснованным домыслам.

Если отладочная часть заключается в одном вызове "печаталки", то, разумеется, лучше эту самую печаталку определить через дефайн.
А вот если эта часть, например, требует каких-либо осмысленных действий, помимо одного вызова, то лучше оформить ее блоком, а проверку
условия выполнить средствами языка, а не препроцессора:

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

Может быть мне конечно показалось но какой смысл было акцентироваться на неточностях и плести про красноглазие ? хотя если говорить формально я написал достаточно точно - код после препроцессора до компилятора вообще не дойдет, тогда как с if он останется на усмотрение компилятора, но то что вручную выковыривать не надо - я согласен, соврал - например gcc всегда выкинет этот код сам и это помоему даже не отключить никак.



На любителя - чем это лучше
#ifdef DEBUG
{
// Объявляем локальные переменные
...

Форматированием (глаз не спотыкается) и лаконичностью.

Вариант с обычным if идеологически правильнее, чем с #ifdef потому, что прежде чем выкинуть недостижимый код, компилятор всё-таки проверит его корректность, в отличии от препроцессора. Автор темы задавал этот-же вопрос на другом форуме и там так-же возникла конфронтация #ifdef(DEBUG) VS if(DEBUG). Можете почитать мои доводы там.

Хороший форум - добрый, читал что-то там пару раз но не зарегистрирован, поэтому тут отвечу. Идеология тут ни при чем - для констант имеющих заранее определенное значение всегда рекомендуется использовать средства компилятора - это не потому что нужно проверять что и как и компилить 10 раз в случае чего а потому что у компилятора появляется больше вариантов для оптимизации конечного кода. Здесь речь об отладкке - и собирать я лично начну именно с отладочного варианта если уж написал какой-то отладочный код, поэтому никаких 10-20 раз не будет, но если проект большой как например ядро Linux препроцессор выкинет отладочный код (и вообще весь который не нужен для цели сборки) и ждать каждый раз когда компилятор его проверит не нужно - а прождать в случае 20 млн SLOC можно нехило.