Отступы #defines

Question 1

Я знаю, что #defines и т. Д. Обычно не имеют отступа. Зачем?

Я сейчас работаю над кодом, который представляет собой ужасную смесь #defines, #ifdefs, #elses, #endifs и т. Д. Все это часто смешивается с обычным кодом C. Отсутствие отступов#define s делает их трудными для чтения. А смесь кода с отступом и #defines без отступа - это кошмар.

В чем преимущество отсутствия отступов #define? Делает ли меня плохим человеком, если я им уступаю? Разве это не лучше?

#ifdef SDCC
    #if DEBUGGING == 1
        #if defined (pic18f2480)
            #define FLASH_MEMORY_END 0x3DC0
        #elif defined (pic18f2580)
            #define FLASH_MEMORY_END 0x7DC0
        #else
            #error "Can't set  up flash memory end!"
        #endif
    #else
        #if defined (pic18f2480)
            #define FLASH_MEMORY_END 0x4000
        #elif defined (pic18f2580)
            #define FLASH_MEMORY_END 0x8000
        #else
            #error "Can't set  up flash memory end!"
        #endif
    #endif
#else
    #if DEBUGGING == 1
        #define FLASH_MEMORY_END 0x7DC0
    #else
        #define FLASH_MEMORY_END 0x8000
    #endif
#endif

Question 2

Препроцессор до ANSI C не допускал пробелов между началом строки и символом «#»; ведущий знак "#" всегда должен быть помещен в первый столбец.

Компиляторы C до ANSI в наши дни не существуют. Используйте любой стиль (пробел перед "#" или пробел между "#" и идентификатором), который вы предпочитаете.

http://www.delorie.com/gnu/docs/gcc/cpp_48.html

Question 3

Как уже говорилось, некоторые компиляторы Pre-ANSI требовали, чтобы # был первым символом в строке, но они не требовали присоединения к нему директивы препроцессора, поэтому отступы были сделаны таким образом.

#ifdef SDCC
#  if DEBUGGING == 1
#    if defined (pic18f2480)
#      define FLASH_MEMORY_END 0x3DC0
#    elif defined (pic18f2580)
#      define FLASH_MEMORY_END 0x7DC0
#    else
#      error "Can't set  up flash memory end!"
#    endif
#  else
#    if defined (pic18f2480)
#      define FLASH_MEMORY_END 0x4000
#    elif defined (pic18f2580)
#      define FLASH_MEMORY_END 0x8000
#    else
#      error "Can't set  up flash memory end!"
#    endif
#  endif
#else
#  if DEBUGGING == 1
#    define FLASH_MEMORY_END 0x7DC0
#  else
#    define FLASH_MEMORY_END 0x8000
#  endif
#endif

Я часто видел этот стиль в старых заголовках Unix, но я ненавижу его, поскольку синтаксическая окраска часто не работает в таком коде. Я использую очень заметный цвет для директив препроцессора, чтобы они выделялись (они находятся на мета-уровне, поэтому не должны быть частью обычного потока кода). Вы даже можете видеть, что SO не окрашивает последовательность полезным способом.

Question 4

Что касается синтаксического анализа директив препроцессора, стандарт C99 (и стандарт C89 до него) четко определял последовательность операций, логически выполняемых компилятором. В частности, я считаю, что это означает, что этот код:

/* */ # /* */ include /* */ <stdio.h> /* */

эквивалентно:

#include <stdio.h>

Хорошо это или плохо, но GCC 3.4.4 с '-std = c89 -pedantic', в любом случае, принимает строку с комментариями. Я не защищаю это как стиль - ни на секунду (это ужасно). Я просто думаю, что это возможно.

В разделе 5.1.1.2 «Фазы перевода» ИСО / МЭК 9899: 1999 говорится:

[Сопоставление символов, включая триграфы]

[Соединение строк - удаление новой строки с обратной косой чертой]

Исходный файл разбивается на токены предварительной обработки и последовательности символов пробела (включая комментарии). Исходный файл не должен заканчиваться токеном частичной предварительной обработки или частичным комментарием. Каждый комментарий заменяется одним пробелом. Символы новой строки сохраняются. Будет ли каждая непустая последовательность символов пробела, кроме новой строки, сохраняться или заменяться одним символом пробела, определяется реализацией.

Выполняются директивы предварительной обработки, расширяются вызовы макросов, [...]

Раздел 6.10 Директивы предварительной обработки говорит:

Директива предварительной обработки состоит из последовательности токенов предварительной обработки, которая начинается с токена предварительной обработки #, который (в начале фазы трансляции 4) является либо первым символом в исходном файле (необязательно после пробела, не содержащего символов новой строки), либо которым следует за пробелом, содержащим хотя бы один символ новой строки, и заканчивается следующим символом новой строки.

Единственный возможный спор - это выражение в скобках «(в начале фазы 4 перевода)», которое может означать, что комментарии перед хешем должны отсутствовать, поскольку в противном случае они не заменяются пробелами до конца фазы 4.

Как отмечали другие, предварительные стандартные препроцессоры C не вели себя единообразно во многих отношениях, а пробелы перед и в директивах препроцессора были одной из областей, где разные компиляторы делали разные вещи, в том числе не распознавали директивы препроцессора с пробелами перед ними. .

Примечательно, что удаление обратной косой черты и новой строки происходит до анализа комментариев. Следовательно, не следует заканчивать //комментарии обратной косой чертой.

Question 5

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

Одна вещь, которая продолжает мешать мне (и иногда убеждает меня прекратить попытки), - это то, что многие или большинство редакторов / IDE перебрасывают директиву в столбец 1 при малейшей провокации. Что чертовски раздражает.

Question 6

Сейчас я считаю, что это в основном выбор стиля. Я думаю в какой-то момент в далеком прошлом не все компиляторы поддерживали идею отступа, определяемого препроцессором. Я провел небольшое исследование и не смог подтвердить это утверждение. Но в любом случае, похоже, все современные компиляторы поддерживают идею отступа макроса препроцессора. У меня нет копии стандарта C или C ++, поэтому я не знаю, является ли это стандартным поведением или нет.

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

#if COND1
void foo() {
  #if COND2
  int i;
    #if COND3
  i = someFunction()
  cout << i << eol;
    #endif
  #endif
}
#endif

Question 7

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

Лично я считаю, что большую часть времени полезно держать их без отступов, потому что эти директивы работают отдельно от остального кода. Такие директивы, как #ifdef, обрабатываются препроцессором до того, как компилятор когда-либо увидит ваш код, поэтому блок кода после директивы #ifdef может даже не быть скомпилирован .

Хранение директив, визуально отделенных от остальной части вашего кода, более важно, когда они перемежаются с кодом (а не с выделенным блоком директив, как в приведенном вами примере).

Question 8

В данный момент я работаю над кодом, который содержит ужасную смесь #defines, #ifdefs, #elses, #endifs, #etc. Все это часто смешивается с обычным кодом C. Отсутствие отступов в #defines затрудняет их чтение. А сочетание кода с отступом и #defines без отступа - это кошмар.

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

#ifdef FOO
/* a lot of code */
#endif /* FOO */

#ifndef FOO
/* a lot of code */
#endif /* not FOO */

Question 9

Практически во всех доступных в настоящее время компиляторах C / CPP это не ограничено. Пользователь сам решает, как вы хотите выровнять код. Так счастливого кодирования.