Dlaczego makra preprocesora są złe i jakie są alternatywy?

Powiedzenie "makra są złe" zwykle odnosi się do użycia #define, a nie #pragma.

W szczególności wyrażenie odnosi się do tych dwóch przypadków:

• Definiowanie liczb magicznych jako makr

• Używanie makr do zastępowania wyrażeń

Z nowym C++ 11 jest prawdziwa alternatywa po tylu latach ?

Tak, dla pozycji z powyższej listy (liczby magiczne powinny być zdefiniowane za pomocą const / constexpr i wyrażenia powinny być zdefiniowane za pomocą funkcji [normal/inline/template/inline template].

Oto niektóre z problemów wprowadzonych przez definiowanie liczb magicznych jako makr i zastępowanie wyrażeń makrami (zamiast definiowania funkcji do oceny tych wyrażeń):

• Podczas definiowania makr dla liczb magicznych kompilator nie zachowuje informacji o typie dla zdefiniowanych wartości. Może to powodować Ostrzeżenia kompilacji (i błędy) i mylić ludzi debugujących kod.

• Definiując makra zamiast funkcji, Programiści używający tego kodu oczekują, że będą działać jak funkcje, a tak nie jest.

Rozważ ten kod:

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

int a = 5;
int b = 4;

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

Spodziewasz się, że a i c będą 6 po przypisaniu do c (tak jak byłoby, używając STD:: max zamiast makra). Zamiast tego Kod wykonuje:

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

Poza tym makra nie obsługują przestrzeni nazw, co oznacza, że definiowanie makr w kodzie ograniczy klienta kod w jakich nazwach mogą używać.

Oznacza to, że jeśli zdefiniujesz makro powyżej (dla max), nie będziesz już mógł #include <algorithm> w żadnym z poniższych kodów, chyba że wyraźnie napiszesz:

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

Posiadanie makr zamiast zmiennych / funkcji oznacza również, że nie można przyjąć ich adresu:

• Jeśli makro-jako-stała jest obliczana na liczbę magiczną, nie można przekazać jej przez adres

• W przypadku makra jako funkcji nie można użyć go jako predykatu lub przyjmuje adres funkcji lub traktuje ją jako funktor.

Edit: jako przykład poprawna alternatywa dla #define max powyżej:

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

Robi to wszystko, co robi makro, z jednym ograniczeniem: jeśli typy argumentów są różne, wersja szablonu zmusza cię do bycia jawnym (co faktycznie prowadzi do bezpieczniejszego, bardziej jawnego kodu): {]}

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

Jeśli ta wartość max jest zdefiniowana jako makro, kod zostanie skompilowany (z ostrzeżeniem).

Jeśli max jest zdefiniowany jako funkcja szablonu, kompilator zwróci uwagę na niejednoznaczność, a ty musisz powiedzieć albo max<int>(a, b) albo max<double>(a, b) (i tym samym wyraźnie określić swój zamiar).

Częstym problemem jest to:

#define DIV(a,b) a / b

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

Wydrukuje 10, a nie 5, ponieważ preprocesor rozszerzy go w ten sposób:

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

Ta wersja jest bezpieczniejsza:

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

Makra są cenne szczególnie przy tworzeniu kodu generycznego (parametry makra mogą być dowolne), czasami z parametrami.

Więcej, ten kod jest umieszczony (tj. wstawione) w punkcie makra.

OTOH, podobne wyniki można uzyskać z:

• Funkcje przeciążone (różne typy parametrów)

• Templates, in C++ (generic parameter types and values)

• Funkcje Inline (umieść kod, w którym są wywoływane, zamiast przeskakiwać do definicji jednopunktowej-jednak jest to raczej rekomendacja dla kompilatora).

Edit: A dlaczego makro jest złe:

1) Brak sprawdzania typu argumentów( nie mają typu), więc można je łatwo pomylić 2) czasami rozbudować do bardzo skomplikowanego kodu, który może być trudny do zidentyfikowania i zrozumienia w wstępnie przetworzonym pliku 3) łatwo jest tworzyć podatny na błędy kod w makrach, takich jak:

#define MULTIPLY(a,b) a*b

A następnie wywołaj

MULTIPLY(2+3,4+5)

Że rozszerza się w

2+3*4+5 (i nie w: (2+3)*(4+5)).

Aby mieć to drugie, należy zdefiniować:

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

Myślę, że problem polega na tym, że makra nie są dobrze zoptymalizowane przez kompilator i są "brzydkie" do odczytu i debugowania.

Często dobrą alternatywą są funkcje ogólne i / lub funkcje inline.

Nie sądzę, aby było coś złego w używaniu definicji lub makr preprocesora, jak je nazywasz.

Są (meta) koncepcją języka znalezioną w c / C++ i jak każde inne narzędzie mogą ułatwić Ci życie, jeśli wiesz, co robisz. Problem z makrami polega na tym, że są one przetwarzane przed kodem c/C++ i generują nowy kod, który może być wadliwy i powodować błędy kompilatora, które są oczywiste. Z drugiej strony mogą pomóc ci zachować czysty kod i zapisać dużo piszesz, jeśli używasz poprawnie, więc sprowadza się to do osobistych preferencji.

Makra w C / C++ mogą służyć jako ważne narzędzie do kontroli wersji. Ten sam kod może być dostarczony do dwóch klientów z niewielką konfiguracją makr. Używam takich rzeczy jak

#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

Tego rodzaju funkcjonalność nie jest tak łatwo możliwa bez makr. Makra są w rzeczywistości doskonałym narzędziem do zarządzania konfiguracją oprogramowania, a nie tylko sposobem na tworzenie skrótów do ponownego użycia kodu. Definiowanie funkcji do celów możliwość wielokrotnego użytku w makrach może zdecydowanie stwarzać problemy.