Sollten Präprozessoranweisungen am Anfang einer Zeile stehen?

Lesezeit: 3 Minuten

Vor einiger Zeit habe ich einen (ziemlich alten) C-Compiler entdeckt, der Makros auf diese Weise gescannt hat (Pseudocode):

 if line.startswith("#include") or line.startswith("#define"):
     ...

.. Was für mich die Frage aufgeworfen hat, wo Makros wirklich platziert werden sollten, am Anfang einer Zeile, etwa so:

void stuff()
{
#if defined(WIN32) || defined(_WIN32)
    ...
#else
#if defined(__GNUC__)
    ...
#else
    ...
#endif
#endif
}

Oder eher so (wie ich es mache, zur besseren Lesbarkeit):

void stuff()
{
    #if defined(WIN32) || defined(_WIN32)
    ...
    #else
    #   if defined(__GNUC__)
    ...
    #   else
    ...
    #   endif
    #endif
}

Ist die Art und Weise, wie man den Präprozessorcode einrückt, standardisiert, das heißt, egal wie ich ihn einrücke, es funktioniert immer auf die gleiche Weise?

  • Ich liebe den Pseudocode :D. “Pseudocode” ist eine großartige Sprache.

    – Matt Tischler

    18. Januar 2011 um 8:58 Uhr


Einige alte C-Compiler verlangten, dass die #define (zum Beispiel) mit dem linken Rand bündig sein:

#define FOO bar

Andere C-Compiler verlangten nur, dass die # am linken Rand sein, also könnten Sie:

#    define FOO bar

Neuere C-Compiler akzeptieren tendenziell die # nach jedem führenden Leerzeichen:

    #define FOO bar

Wenn Sie Kompatibilität mit solchen älteren Compilern wünschen, sollten Sie zumindest Ihre # in der ersten Spalte. Wenn Kompatibilität keine Rolle spielt, dann liegt es an Ihnen.

Ich würde normalerweise versuchen, nicht einzubetten #ifdef Blöcke innerhalb von Funktionen, sodass die ganze Frage, ob sie eingerückt werden sollten, meistens wegfällt.

  • Um die Unterstützung von Compilern wie ZetaC, die glücklicherweise nur noch sehr selten verwendet werden, müsste ich mir wohl keine Gedanken machen 😉

    Benutzer350814

    18. Januar 2011 um 9:09 Uhr

  • “Wenn Sie Kompatibilität mit solchen älteren Compilern wünschen” – dann müssen Sie herausfinden, wo sie sonst nicht einmal C89 implementieren, geschweige denn C99?

    – Steve Jessop

    18. Januar 2011 um 10:04 Uhr

  • Sie sprechen hier von Compilern vor ANSI K&R v1. Vergessen Sie also Funktionsdeklarationen und Parameterlisten.

    – MSalter

    18. Januar 2011 um 13:41 Uhr

aus gcc C-Präprozessor-Dokumentation:

Vorverarbeitungsdirektiven sind Zeilen in Ihrem Programm, die mit beginnen #'. Whitespace is allowed before and after the#’.

  • @Will: Sie haben diesen Kommentar wahrscheinlich geschrieben, bevor ich den zweiten Satz zum Zitat hinzugefügt habe 🙂

    – Davka

    18. Januar 2011 um 8:51 Uhr

Nein, sie müssen nicht am Zeilenanfang stehen, dürfen aber nur Leerzeichen (Leerzeichen, Tabulatoren, …) davor haben.

Normalerweise werden sie an den Anfang der Zeile gestellt, weil sie nicht den Bereichen unterliegen, in denen sie sich befinden, da sie vor dem eigentlichen C-Code vorverarbeitet werden.

  • Leerzeichen sind nach dem erlaubt #wie in ` # include `

    – David Rodríguez – Dribeas

    18. Januar 2011 um 8:54 Uhr

  • @peoro Ich denke, dass “sie können nur Leerzeichen vor sich haben” mehrdeutig ist – dh es könnte bedeuten “sie können Leerzeichen vor sich haben, aber nirgendwo anders” oder es könnte bedeuten “vor ihnen können sie nur Leerzeichen haben und nichts anders”. Du meinst natürlich letzteres, aber die Formulierung ist mehrdeutig.

    – davmac

    6. November 2018 um 12:26 Uhr

Benutzer-Avatar
RvdK

Egal. Sehen Sie es so, wenn Code nicht identifiziert wurde und in einer Zeile trotzdem kompiliert werden sollte (nur Code, Präprozessor/includes und einige andere Dinge benötigen eine separate Zeile).

Bearbeiten: Scheint so zu sein, dass wirklich alte Compiler diesbezüglich wählerisch sind. Der Präprozessor sollte sich in einer Zeile befinden, genau wie andere Nicht-Code-Dinge wie Includes

Ich glaube nicht, dass sich der Compiler “kümmert”, wenn Sie Leerzeichen vor dem Vorverarbeiteten haben – es sollte dasselbe sein …

1300090cookie-checkSollten Präprozessoranweisungen am Anfang einer Zeile stehen?

This website is using cookies to improve the user-friendliness. You agree by using the website further.

Privacy policy