Почему макросы препроцессора злые и каковы альтернативы?

выражение "макросы-это зло" обычно относится к использованию #define, а не #pragma.

в частности, выражение относится к этим двум случаям:

• определение магических чисел как макросов

• использование макросов для замены выражения

С Новым C++ 11 есть реальная альтернатива после стольких лет ?

Да, для элементов в списке выше (магия числа должны быть определены с const/пользователем и выражения должны быть определены с [нормальный/встроенные/шаблон/встроенного шаблона] функции.

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

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

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

рассмотрим этот код:

#define max(a, b) ( ((a) > (b)) ? (a) : (b) )

int a = 5;
int b = 4;

int c = max(++a, b);

вы ожидаете, что a и c будут равны 6 после назначения c (как это было бы с использованием std::max вместо макроса). Вместо этого код выполняет:

int c = ( ((++a) ? (b)) ? (++a) : (b) ); // after this, c = a = 7

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

это означает, что если вы определяете макрос выше (для max), вы больше не сможете #include <algorithm> в любом из приведенных ниже кодов, если вы явно не пишете:

#ifdef max
#undef max
#endif
#include <algorithm>

наличие макросов вместо переменных / функций также означает, что вы не можете взять их адрес:

• если макрос-как-постоянное значение магическое число, вы не можете передать его по адресу

• макрос-как-функции, вы не можете использовать его в качестве предиката или взять адрес функции или рассматривать его как функтор.

Edit: в качестве примера, правильная альтернатива #define max выше:

template<typename T>
inline T max(const T& a, const T& b)
{
    return a > b ? a : b;
}

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

int a = 0;
double b = 1.;
max(a, b);

если этот Макс определен как макрос, код будет компилироваться (с предупреждением).

если этот max определен как функция шаблона, компилятор укажет на двусмысленность, и вы должны сказать либо max<int>(a, b) или max<double>(a, b) (и таким образом явно заявить о своем намерении).

общая беда заключается в следующем:

#define DIV(a,b) a / b

printf("25 / (3+2) = %d", DIV(25,3+2));

он будет печатать 10, а не 5, потому что препроцессор будет расширять его таким образом:

printf("25 / (3+2) = %d", 25 / 3 + 2);

эта версия безопаснее:

#define DIV(a,b) (a) / (b)

макросы особенно ценны для создания общего кода (параметры макроса могут быть любыми), иногда с параметрами.

еще, этот код помещается (т. е. вставлено) в точке макроса используется.

OTOH, аналогичные результаты могут быть достигнуты с:

• перегруженные функции (различные типы параметров)

• шаблоны в C++ (стандартные типы и значения параметров)

• inline функции (поместите код, где они вызываются, вместо перехода к одноточечному определению-однако это скорее рекомендация для компилятора).

edit: что касается того, почему макрос плох:

1) нет проверки типа аргументов (у них нет типа), поэтому их можно легко использовать неправильно 2) иногда расширяется в очень сложный код, который может быть трудно идентифицировать и понять в предварительно обработанном файле 3) это легко сделать ошибки кода в макросах, такие как:

#define MULTIPLY(a,b) a*b

а потом позвоните

MULTIPLY(2+3,4+5)

, которая расширяется в

2+3*4+5 (и не в: (2+3)*(4+5)).

чтобы иметь последнее, вы должны определить:

#define MULTIPLY(a,b) ((a)*(b))

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

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

Я не думаю, что есть что-то не так с использованием препроцессорных определений или макросов, как вы их называете.

это (мета) языковая концепция, найденная в c/c++, и, как и любой другой инструмент, они могут облегчить вашу жизнь, если вы знаете, что делаете. Проблема с макросами заключается в том, что они обрабатываются перед вашим кодом c/C++ и генерируют новый код, который может быть неисправен и вызывать ошибки компилятора, которые почти очевидны. С другой стороны, они могут помочь вам сохранить ваш код в чистоте и сэкономить вам много набрав при правильном использовании, так что это сводится к личным предпочтениям.

макросы в C / C++ могут служить важным инструментом для контроля версий. Один и тот же код может быть доставлен двум клиентам с незначительной конфигурацией макросов. Я использую такие вещи, как

#define IBM_AS_CLIENT
#ifdef IBM_AS_CLIENT 
  #define SOME_VALUE1 X
  #define SOME_VALUE2 Y
#else
  #define SOME_VALUE1 P
  #define SOME_VALUE2 Q
#endif

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