Вопрос

Будучи C новичок, я хотел бы услышать, какой макрос используют разработчики "define".Я подумывал о том, чтобы поместить это в заголовок, чтобы пропустить многословие, к которому я привык:

#define TS_ typedef struct {  
#define _TS(x) } x;

#define I(x)_ { int i; for ( i = 1; i <= x; i++ ) {  
#define _I } }

Могу ли я добавить \ t и т.д. В эти макросы?Поскольку я хотел бы передать свой исходный код за вычетом дополнительного включения:

#define TS_ typedef struct {\n
#define _TS(x) } x;\n

#define I(x)_ { int i;\n\tfor ( i = 1; i <= x; i++ ) {\n 
#define _I \t}\n}\n

Сработает ли это?

т. е.:Могу ли я использовать proprocessor для замены моего исходного кода моим личным include на форматированный исходный код без include?

Ссылки на полезные советы и рекомендации по препроцессору также приветствуются.

Это было полезно?

Решение

Вы можете вставить пробел, экранируя символ новой строки

#define SOMETHING whatever\
This is part of the macro

Но, как говорили другие, это не очень хороший способ сделать это.

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

Другие советы

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

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

Вы идете по неверному пути. НЕ составляйте свои собственные директивы cpp, которые незнакомы другим - это сделает ваш код трудным для понимания и в какой-то момент поддержанным.

Попробуйте найти хороший код C для чтения - хороший код C не использует эти вещи по уважительной причине.

НЕ ДЕЛАЙТЕ ЭТОГО . Никто другой не сможет прочитать ваш код.

В качестве предостерегающего примера посмотрите Исходные тексты Стива Борна для оболочки Bourne , где он использовал макросы для написания кода в стиле пиджина Алголь.

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

Если вы делаете это только для себя, не стесняйтесь #define делать все, что захотите, но ожидайте, что, как только вы начнете работать с кем-то (или для кого-то), вы не будете возможность продолжать использовать такие вещи.

Использование макросов C без необходимости может привести к боли, особенно если вы попытаетесь использовать его для расширения кода. Существуют варианты использования макросов C, но это не так.

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

В общем, я полностью согласен с другими респондентами, которые говорят, что вы не должны определять свои собственные макросы исключительно ради экономии текста. Запутывание не стоит. Кроме того, конкретные макросы, которые вы предлагаете, являются отвратительными. Однако в первом издании Страуструпа он делает что-то, что мне скорее нравится (иногда):

#define Kase break; case

Я привык к elif-конструкции Python, поэтому часто определяю следующее:

#define elif(test) else if(test)

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

if(...) ...
else if(...) ...
else ...

... должно быть ...

if(...)
{
    ...
}

else
    if(...)
    {
        ...
    }

    else
    {
        ...
    }

С моим макросом это становится:

if(...)
{
    ...
}

elif(...)
{
    ...
}

else
{
    ...
}

Всегда лучше передать переменную цикла макросу.Блок - макрос имеет определенные проблемы с оптимизацией.Все компиляторы не гарантируют оптимизированный obj-код для переменных "области действия блока".

например, следующий код, скомпилированный без каких-либо параметров оптимизации для gcc, выводит два отдельных адреса для &i .И один и тот же код при компиляции с опцией -O2 выведет один и тот же адрес в обоих блоках.

{
    int i;
    printf("address of i in first block is %u\n", &i);
}
{
    int i;
    printf("address of i in sec block is %u\n", &i);
}

Присвоение языковым конструкциям соответствующих имен делает код более читабельным.Мне нравится ваша идея, если вы сформулируете ее следующим образом.

#define GREEN 1
#define YELLOW 2
#define RED 3

# define NUM_COLORS 3

#define COLOR_ITER (color,i)           \
    for(i=GREEN, color = colors[i];    \
        i < NUM_COLORS;                \
        color = colors[++i])

int colors[3] = {GREEN, YELLOW, RED};

int
fun () {

    int j;
    color_t clr;

    COLOR_ITER(clr, j) {
        paint(clr);
    }

}

Здесь, независимо от того, как он написан, макрос COLOR_ITER по своему названию подразумевает, что вы выполняете цикл для всех доступных цветов и делаете "что-то" для каждого цвета.И это очень простой в использовании макрос.

И ваш вопрос

Могу ли я использовать proprocessor для замены моего исходного кода моим личным include на форматированный исходный код без include?

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

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top