Apalopohapa
Es ist möglich, den Wert einer Präprozessorvariablen in stderr zu drucken C? Was ich z.B. gerade habe ist:
#define PP_VAR (10)
#if (PP_VAR > 10)
#warning PP_VAR is greater than 10
#endif
Aber was ich machen möchte ist:
#define PP_VAR (10)
#if (PP_VAR > 10)
#warning PP_VAR=%PP_VAR%
#endif
Ist so etwas möglich in C?
Sie können den Wert einer Präprozessorvariablen unter Visual Studio ausdrucken. Das Folgende gibt den Wert von _MSC_VER aus:
#define STRING2(x) #x
#define STRING(x) STRING2(x)
#pragma message(STRING(_MSC_VER))
Bin mir aber nicht sicher wie Standard das ist.
Es ist nicht Standard, aber GCC, MSVC, CLANG … (wahrscheinlich unterstützen es andere auch)
– Ideengeber42
21. Juni 2015 um 2:45 Uhr
VisualStudio anscheinend nicht
– derHugo
21. September 2018 um 12:13 Uhr
@derHugo: Entschuldigung, aber ich habe gerade mit Visual Studio 2017 und C ++ 17 getestet und dies funktioniert ohne Probleme. Ich habe mit einer benutzerdefinierten Präprozessorvariablen getestet, nicht mit _MSC_VER !
– schlebe
7. März 2019 um 13:54 Uhr
Dies funktioniert mit GCC 4.4.3:
#define STRING2(x) #x
#define STRING(x) STRING2(x)
#pragma message "LIBMEMCACHED_VERSION_HEX = " STRING(LIBMEMCACHED_VERSION_HEX)
Erträge:
src/_pylibmcmodule.c:1843: note: #pragma message: LIBMEMCACHED_VERSION_HEX = 0x01000017
Viele C-Compiler unterstützen #warning (ist aber nicht durch den C-Standard definiert).
GCC führt jedoch zumindest keine Vorverarbeitung der folgenden Daten durch, was bedeutet, dass der Wert einer Variablen schwer zu erkennen ist.
#define PP_VAR 123
#warning "Value of PP_VAR = " PP_VAR
#warning "Value of PP_VAR = " #PP_VAR
#warning "Value of PP_VAR = " ##PP_VAR
GCC produziert:
x.c:2:2: warning: #warning "Value of PP_VAR = " PP_VAR
x.c:3:2: warning: #warning "Value of PP_VAR = " #PP_VAR
x.c:4:2: warning: #warning "Value of PP_VAR = " ##PP_VAR
Wenn Sie also sagen “Es ist schwer, den Wert einer Variablen zu sehen”, meinen Sie wirklich, dass Sie ihn NICHT sehen können.
– Nick
29. September 2011 um 18:53 Uhr
Grob – ja; Ich habe keine Möglichkeit gefunden, es zu sehen, was nicht dasselbe ist wie “es gibt keine Möglichkeit, es zu sehen”.
– Jonathan Leffler
29. September 2011 um 19:20 Uhr
ich denken das versuche ich zu tun …. Ich möchte wissen, was die Laufzeitbibliothek definiert SSIZE_MAX als String (wie 0, INT_MAX oder LONG_MAX), aber die Sehnsucht kehrt nur zurück SSIZE_MAX (die linke Seite der Definition).
– jww
28. März 2016 um 5:43 Uhr
Verwenden Sie den Präprozessor-Operator zum Einfügen von Token: ##TOKEN_NAME
Wie bereits erwähnt, sind die von Ihnen verwendeten Präprozessordirektiven nicht standardmäßig, also YMMV.
Nun, was Sie tun, ist eigentlich nicht standardisiert. Erstens ist die “#warning”- oder “#warn”-Direktive kein Standard. Zweitens muss die Zeile bei Verwendung des Präprozessors mit dem Pfund-Symbol ohne Leerzeichen beginnen:
#ifdef BLAH1
# define BLAH2 // OK, because pound is at the very left.
#endif
#ifdef BLAH3
#define BLAH4 // Works on many compilers, but is non-standard.
#endif
Da Sie bereits eine nicht standardmäßige Erweiterung verwenden, müssen Sie in der Dokumentation des jeweiligen Präprozessors/Compilers nachschlagen, den Sie verwenden, um zu sehen, was dort über “#warning” steht.
Ihr zweiter Punkt ist nicht korrekt – C89 hat diese Einschränkung aufgehoben. Das # muss das erste Zeichen in der Zeile sein, aber es darf ein Leerzeichen (aber kein Kommentar) vorangestellt werden.
– Jonathan Leffler
30. Juli 2009 um 3:05 Uhr
Vielen Dank. Ich kann nicht glauben, dass ich immer noch im Mittelalter lebe. Können Sie mir das entsprechende Dokument dafür nennen?
– Michael Aaron Safyan
30. Juli 2009 um 3:09 Uhr
Wow. Ich kam später zum Spiel als ich dachte – ich wusste überhaupt nichts von dieser Einschränkung.
– Michael Köhne
30. Juli 2009 um 3:15 Uhr
@Jonathan: Es ist absolut kein Problem, einer Vorverarbeitungsanweisung einen Kommentar voranzustellen (mindestens c Kommentar /*..*/), er wird in Übersetzungsphase 3 durch ein einzelnes Leerzeichen ersetzt. Vorverarbeitungsdirektiven werden in Phase 4 behandelt und sind daher nicht von vorangehenden c-Kommentaren betroffen.
– Artur
23. Juni 2015 um 15:17 Uhr
@Artur: Du hast Recht – aber in den schlechten alten Zeiten (wirklich alte Zeiten, vor C89-Standardtagen) waren Kommentare nicht erlaubt. Meine Verwechslung. (Wohlgemerkt, es müsste einen sehr, sehr guten Grund geben, einen Kommentar vor einer Präprozessordirektive einzufügen, und mir fällt keiner ein.)
– Jonathan Leffler
23. Juni 2015 um 15:22 Uhr
Ihr zweiter Punkt ist nicht korrekt – C89 hat diese Einschränkung aufgehoben. Das # muss das erste Zeichen in der Zeile sein, aber es darf ein Leerzeichen (aber kein Kommentar) vorangestellt werden.
– Jonathan Leffler
30. Juli 2009 um 3:05 Uhr
Vielen Dank. Ich kann nicht glauben, dass ich immer noch im Mittelalter lebe. Können Sie mir das entsprechende Dokument dafür nennen?
– Michael Aaron Safyan
30. Juli 2009 um 3:09 Uhr
Wow. Ich kam später zum Spiel als ich dachte – ich wusste überhaupt nichts von dieser Einschränkung.
– Michael Köhne
30. Juli 2009 um 3:15 Uhr
@Jonathan: Es ist absolut kein Problem, einer Vorverarbeitungsanweisung einen Kommentar voranzustellen (mindestens c Kommentar /*..*/), er wird in Übersetzungsphase 3 durch ein einzelnes Leerzeichen ersetzt. Vorverarbeitungsdirektiven werden in Phase 4 behandelt und sind daher nicht von vorangehenden c-Kommentaren betroffen.
– Artur
23. Juni 2015 um 15:17 Uhr
@Artur: Du hast Recht – aber in den schlechten alten Zeiten (wirklich alte Zeiten, vor C89-Standardtagen) waren Kommentare nicht erlaubt. Meine Verwechslung. (Wohlgemerkt, es müsste einen sehr, sehr guten Grund geben, einen Kommentar vor einer Präprozessordirektive einzufügen, und mir fällt keiner ein.)
– Jonathan Leffler
23. Juni 2015 um 15:22 Uhr
