Wer kann mir dieses Define erklären?

Hans R. schrieb:

> Die Trennung duch Semikolom im define ist mir unbekannt.

Nun, die rechte Seite eines #define ist ja weiter nichts als das,
was bei Aufruf des Makros dann als Text stattdessen eingesetzt
wird.  Insofern kannst du natürlich dort erst einmal beliebige
Zeichen stehen haben.

Allerdings ist ein Semikolon innerhalb runder Klammern in der Tat
seltsam, und in vielen Fällen dürfte die Verwendung dieses Makros
wohl zu einem Syntaxfehler führen.

> Ich würde
> denken, das es folgendes bedeutet:

Das war wohl die Intention.

Besser würde man es so schreiben:

1

#define TEST() do { PORTD &= ~(1<<PD1)); (PORTD |= ( (1<<PD3) | (1<<PD7) ); } while(0)

Diese do … while(0)-Konstruktion erscheint auf den ersten Blick
seltsam, hat aber den Vorteil, dass sie syntaktisch in der Tat ein
einziges Statement ist.  Da sie einen Block innerhalb geschweifter
Klammern beinhaltet, darf man darin wiederum weitere Statements mit
Semikolon trennen.

Der Vorteil dieses Konstrukts kommt vor allem dann zum Tragen, wenn
man schreiben möchte:

1

if (bedingung)

2

  TEST();

3

else

4

  MACHWASANDERES();

> Wie wäre es aber, wenn ich nicht nur an PORTD etwas verändern will
> sondern auch an PORTB?

Welche Sub-Statements man da mit Semikolons trennt, ist dem Compiler
am Ende wurscht.

Huh schrieb:
> Nach dem Semikolon ist ein Kommentar...

In welcher Programmiersprache sollte denn eine öffnende runde
Klammer, die einem Semikolon folgt, einen Kommentar einleiten?

In C jedenfalls wohl nicht.

Spätestens, wenn das Macro so verwendet wird

1

if (condition)

2

  TEST();

 
macht man ne Bauchlandung.  Falls eine inline-Funktion wie
 

1

static inline void __attribute__((__always_inline__))

2

TEST (void)

3

{

4

  PORTD &= ~(1<<PD1);

5

  PORTD |= (1<<PD3) | (1<<PD7);

6

}

 
ausscheidet, wählt man besser folgendes Konstrukt:
 

1

#define TEST()                    \

2

  do {                            \

3

    PORTD &= ~(1<<PD1);           \

4

    PORTD |= (1<<PD3) | (1<<PD7); \

5

  } while (0)

Huh schrieb:
> Ich denke, daß es NICHT innerhalb einer Klammer ist.

OK, verzählt.

Aber der Rest passt schon, und Johann tutet ja ins gleiche Horn –
wobei er völlig Recht hat, dass eine inline-Funktion übersichtlicher
ist.

Wenn ich das so schreibe, dann meckert der GCC-Compiler:

Error    expected identifier or '(' before 'do'
Error    expected identifier or '(' before 'while'


#define Test()
do
{
  PORTD &= ~(1<<PD2);
  PORTD |= (1<<PD3);
        PORTB |= (1<<PB3);
} while (0)

Hans R. schrieb:
> Wenn ich das so schreibe, dann meckert der GCC-Compiler:

Kann nicht sein.  Beim #define kann er noch gar nicht meckern.

Entscheidend ist die Stelle, an der du "Test()" verwendest, aber die
hast du uns nicht gezeigt.

Johann L. schrieb:
> ausscheidet, wählt man besser folgendes Konstrukt:

wozu das do und while(0)?
die geschweiften klammern reichen aus.

ja, ok, aber wer vor 'else' ein semikolon setzt ist selbst schuld.
mit deinem makro funktioniert dafür der fall ohne 'else' nicht bzw. nur 
mit ';;'

Joe F. schrieb:
> ja, ok, aber wer vor 'else' ein semikolon setzt ist selbst schuld.

Aha.  Du meinst also

1

if (cond)

2

  a = sin(x)

3

else

4

  a = cos(x);

wäre legales C?

Wenn du das nicht meinst, dann solltest du wohl deine obige Aussage
nochmal überdenken …

Nimm's einfach, wie es ist: dieser do…while(0)-Konstrukt im Body eines
Makros ist das übliche Mittel dafür, dass man den Makro wie einen
normalen Funktionsaufrauf in einer if-Anweisung benutzen kann.

Im übrigen würde es bei dem ganz oben gezeigten Makro in diesem Falle
auch gar nicht helfen, wenn man das Semikolon vom Aufrufer des Makros
in den Makro verlagert: nach dem if steht dann trotzdem nur eine
Anweisung, obwohl zwei gewünscht sind.

Ja, immer geschweifte Klammern nach einem if schreiben ist defensiv
und hilft ebenfalls (und ist daher in manchen Programmierrichtlinien
vorgeschrieben), aber die do…while(0)-Variante hilft eben auch dann,
wenn derjenige, der das if schreibt, sowas nicht von sich aus tut.

Und weil's noch nicht oft genug geschrieben worden ist: eine
inline-Funktion benimmt sich immer syntaktisch wie eine Funktion,
auch ohne derartig seltsam anmutende Tricks, und sie ist auch noch
in der Regel einfacher zu lesen als ein verzwackter Makro.  Man sollte
einer solchen also nach Möglichkeit den Vorzug gegeben.