Gute Programmierpraxis für Makrodefinitionen (#define) in C [closed]

Definieren Sie zum Beispiel niemals ein Makro wie dieses:

#define DANGER 60 + 2

Dies kann potenziell gefährlich sein, wenn wir eine Operation wie diese durchführen:

int wrong_value = DANGER * 2; // Expecting 124

Definieren Sie stattdessen so, weil Sie nicht wissen, wie der Benutzer des Makros es verwenden könnte:

#define HARMLESS (60 + 2)

Das Beispiel ist trivial, aber das erklärt ziemlich genau meine Frage. Gibt es eine Reihe von Richtlinien oder Best Practices, die Sie beim Schreiben eines Makros empfehlen würden?

Vielen Dank für Ihre Zeit!

Sie sollten nicht nur die Argumente in Klammern setzen, sondern auch den zurückgegebenen Ausdruck.

#define MIN(a,b)  a < b ? a : b     // WRONG  

int i = MIN(1,2); // works
int i = MIN(1,1+1); // breaks

#define MIN(a,b)  (a) < (b) ? (a) : (b)   // STILL WRONG

int i = MIN(1,2); // works
int i = MIN(1,1+1); // now works
int i = MIN(1,2) + 1; // breaks

#define MIN(a,b)  ((a) < (b) ? (a) : (b))   // GOOD

int i = MIN(1,2); // works
int i = MIN(1,1+1); // now works
int i = MIN(1,2) + 1; // works

Jedoch, MIN(3,i++) ist noch kaputt…

Die beste Regel ist #defines nur zu verwenden, wenn KEIN ANDERER ANSATZ FUNKTIONIERT! Ich weiß, dass Sie nach C statt C++ fragen, aber denken Sie trotzdem an ihn.

Wenn Sie ein Makro ausführen, das sein Argument ausführen und sich wie ein Ausdruck verhalten soll, ist dies idiomatisch:

 #define DOIT(x) do { x } while(0)

Dieses Formular hat folgende Vorteile:

1. Es braucht ein abschließendes Semikolon
2. Es funktioniert mit Verschachtelungen und geschweiften Klammern, zB mit if/else

Verwenden Sie Klammern um das gesamte Makro und um jedes Argument, auf das in der Erweiterungsliste verwiesen wird:

#define MAX(x, y) ((x) > (y) ? (x) : (y))

Vermeiden Sie es, Makros zu schreiben, die ihre Argumente mehrmals auswerten. Solche Makros verhalten sich nicht wie erwartet, wenn Argumente Nebenwirkungen haben:

MAX(a++, b);

Werde auswerten a++ zweimal wenn a ist größer als b.

Verwenden Sie GROSSBUCHSTABEN für Makros, um deutlich zu machen, dass es sich um ein Makro und nicht um eine Funktion handelt, damit die Unterschiede entsprechend berücksichtigt werden können (eine weitere allgemeine bewährte Vorgehensweise besteht darin, auch keine Argumente mit Nebeneffekten an Funktionen zu übergeben).

Verwenden Sie keine Makros, um Typen wie folgt umzubenennen:

#define pint int *

weil es sich nicht wie erwartet verhält, wenn jemand tippt

pint a, b;

Verwenden Sie stattdessen typedefs.

Verwenden Sie statische konstante Werte anstelle von Makros für konstante Werte, ganzzahlige oder andere. Der Compiler kann sie oft wegoptimieren, und sie bleiben ein Bürger erster Klasse im Typsystem der Sprache.

static const int DANGER = 60 + 2;

Setzen Sie in der Erweiterung Klammern um die Argumente, damit Sie das beabsichtigte Verhalten erhalten, wenn sie einen Ausdruck übergeben.

#define LESS_THAN(X,Y) (((X) < (Y) ? (X) : (Y))

Antwort auf die MAX/MIN-Makros, entnommen aus GCC-Hacks im Linux-Kernel:

#define min(x, y) ({                       \
        typeof(x) _min1 = (x);             \
        typeof(y) _min2 = (y);             \
        (void) (&_min1 == &_min2);         \
        _min1 < _min2 ? _min1 : _min2; })

Verwenden Sie ziemlich eindeutige Namen für Ihre Makros, da sie einen globalen Geltungsbereich haben und mit allem kollidieren können, also:

#define MAX 10

könnte leicht mit anderem Code kollidieren, also:

#define MYPROJECT_MAX 10

oder etwas noch Einzigartigeres wäre besser.

Ich habe Fälle gesehen, in denen ein Konflikt dieser Art keinen Kompilierungsfehler, sondern leicht falschen Code erzeugt hat, sodass er ziemlich heimtückisch sein kann.