Я не спрашиваю, возможно ли #define
макрос внутри функции. Я понимаю, что это возможно, и что макросы — это механизмы предварительной обработки, которые почти копипасты (в некоторой степени). Я спрашиваю, есть ли серьезные причины избегать создания макроса для использования в одной функции, или это просто зависит от сопровождающих кодовой базы в отношении того, что они считают хорошим стилем?
Вот надуманный пример, похожий на мой вариант использования:
int main() {
/* ... */
#define POS(x, y) grid_array[width*(y) + (x)]
/* Use POS(x, y) in this function */
#undef POS
/* ... */
}
Другой способ задать вопрос: Кивнут ли другие разработчики C в знак понимания или отрицательно покачат головой?
Редактировать:
Это не дубликат вопроса «Макрос против функции». Я понимаю (некоторые) различия между ними, например. MIN(a, b) (a)>(b)?(b):(a)
оценивает a
и b
дважды. Я спрашиваю, хорошо ли использовать макрос для одной функции.
В ответе (и комментариях) указано, что мой простой пример не заслуживает использования макроса. Хотя мой реальный вариант использования не так прост, я должен согласиться. «Сохраненный ввод» не заслуживает запутанного кода.
Вот мой реальный вариант использования, если вам интересно:
/* array represents a graph with max degree 2. These operations are domain specific. */
#define CONNECT(a, b, i) {array[8*(a) + i] = b; array[8*(b) + (i+4)%8] = a;}
Несколько связанный поток C++ (не относится к C, потому что C не поддерживает constexpr
): Constexpr против макросов
@AndreasWenzel, но более современные и эффективные языки имеют для этого гораздо лучшие конструкции. C++ — это запутанный беспорядок из наполовину продуманных концепций, наполовину хорошо реализованных. Единственное, чему можно у него научиться, так это тому, чего не следует делать. ИМХО.
Отвечает ли это на ваш вопрос? Макро и функция в C
Не совсем @UlrichEckhardt. Я понимаю (по крайней мере, большинство) различий между макросами и функциями. Я спрашиваю, разумно ли определять макрос, который используется только в одной функции. Спасибо хоть :)
Gcc поддерживает вложенные функции в C. Это может быть удобной альтернативой для POS-подобных макросов.
Основная цель любого языка программирования, помимо шестнадцатеричных значений, состоит в том, чтобы сделать намерение и реализацию более очевидными для читателя. Программы предназначены для чтения людьми и перевода машинами.
В этом смысле, если POS(x,y)
просто избавит вас от необходимости печатать, это может быть полезно для читателя, но вы должны думать о читателе больше, чем о писателе. Любая стоящая программа будет иметь намного больше читателей, чем авторов, поэтому ваша обязанность как писателя состоит в том, чтобы уменьшить их нагрузку.
«это может быть полезно для читателя» — я думаю, вы имеете в виду «писатель», а не «читатель».
Нет, сокращения помогают писателю сократить количество нажатий клавиш, но могут помочь читателю, снизив когнитивную нагрузку. Вот почему такие обозначения, как ++ или +=, важны; они уменьшают когнитивную нагрузку при чтении программы, особенно в современном контексте чрезмерного указания назначения каждой переменной. Это напряжение между письмом для новичка, который предположительно не понимает языка, и беглым, которого раздражает многословие.
Я могу следовать обоим рассуждениям, Андреасу и Мевецу. Но ответ, вероятно, принесет пользу, если вы (mevets) сформулируете, чтобы уменьшить когнитивную нагрузку для пользователей StackOverflow, чтобы оценить обе интерпретации. (Не высмеивая вас, я намеренно использую ваше выражение, потому что я действительно согласен с концепцией и с тем, как вы ее изложили.) Но у вас уже есть мой голос (за то, что я не сказал ни да, ни нет, что я принимаю как ответ на то, что я сначала рассматривался как вопрос, основанный на мнении), поэтому я боюсь, что вы не получите от меня еще один вопрос, даже если вы сделаете то, что я предлагаю. ;-)
Я считаю, что для такого простого примера код становится менее читаемым.