[VS2005] Debuginformationsformat über #define abfragen

[nil]

Hallo,

ich suche nach einer Möglichkeit im Visual Studio 2005 über #defines herauszufinden auf was das Debuginformationsformat gestellt ist.

Wenn es auf /ZI gesetzt ist (Bearbeiten und Fortfahren / Debuginformationsformat=4 in der Projektdatei) expandiert das __LINE__ Makro anscheinend nicht richtig (Kompilierfehler :?: )und ich kann meine Logger Funktionen nicht kompilieren.
Über defines würd ich jetzt gerne /ZI abfangen und ein Logging ohne __LINE__ ausführen.

[Schrompf]

Wie lautet denn der Fehler? Und wie sieht der Code dazu aus? __LINE__ und Konsorten werden nämlich schon vom Präprozessor aufgelöst, da ist noch gar nichts über evtl. Debug-Einstellungen bekannt. Diese Defines sollten *immer* funktionieren.

[nil]

Die Fehlermeldung lautet
error C2065: '__LINE__Var' : undeclared identifier

Der aufrufende Code verwendet folgendes Makro (aus dem Gedächtnis, Tippfehler möglich):

Code: Alles auswählen

#define LOG_FOOTER_AUTO CBaseLogger::Instance().Footer(__FILE__, __LINE__, __FUNCTION__);

Instance ist eine statische Funktion die mir eine CBaseLogger Referenz zurückgibt und die Footer Funktion verlangt const char*, int, const char*.

Das ganze geht wenn ich statt /ZI mit /Zi kompiliere. Dass es daran liegt hatte ich über googlen gefunden gehabt:
http://social.msdn.microsoft.com/Forums ... 5220acedb8

Verwenden tue ich Visual Studio 2005 mit Service Pack 1.

Wenn ich statt __LINE__ z.B. -1 im Makro übergebe kompiliert es bei mir auch mit /ZI.
z.Z. steuere ich über eine #ifdef _DEBUG ob __LINE__ verwendet werden soll über nicht (im Release kompiliere ich ohne /ZI und für den Release habe ich den Logger ja hauptsächlich), aber da ich auch manche Libs im Debug ohne /ZI kompiliere würde ich gernde mit dem #define statt _DEBUG das Debuginformationsformat abfragen lassen.

[kimmi]

Schnellere und portablere Lösung wäre es, auf das Symbol __LINE__ zu testen und das gegebenenefalls zu definieren, sollte es nicht definiert worden sein:

Code: Alles auswählen

#ifndef __LINE__
#define __LINE__ (-1)
#endif

Gruß Kimmi

[nil]

__LINE__ ist definiert, auf #ifndef __LINE__ zu fragen also nix.
Problem ist, dass es beim Expandieren zu einem Compilerfehler kommt, weil eine vom Makro verwendete Variable fehlt (eben error C2065: '__LINE__Var' : undeclared identifier).

Versuche dem Compiler irgendwie eine passende lokale Variable unter die Nase zu reiben führten bei mir zu Warnings wegen Verwendung uninitialisierter lokaler Variablen (selbst wenn ich sie initialisiert habe) und Random Line Numbers in meinem Output.
Auch Lösungen die bei http://www.devarticles.com/c/a/Cplusplu ... s-Right/3/ vorgeschlagen wurden (das __LINE__ Makro funktioniert angeblich auch unter /ZI wenn man es als default Parameter verwendet) haben bei mir den C2065 ausgelöst.

Scheint auch wirklich ein Fehler des Compiliers bzw. des Preprozessors zu sein -> http://support.microsoft.com/kb/199057
Da auch Microsoft vorschlägt /Zi zu verwenden und keine Möglichkeit erwähnt das Debuginformationkevel abzufragen geh ich z.Z. davon aus, dass eine solche Abfrage ist nicht möglich.

Ich kompiliere jetzt jedenfalls im Debug weiter mit /ZI und verwende __LINE__ nur in den Release Builds.

[Eisflamme]

Und wenn du halt prüfst, ob diese __LINE__Var definiert ist und ggf. die __LINE__ s kickst bzw. Mal versucht, die mit nem Wert zu füllen?

[Schrompf]

__LINE__ ist kein Präprozessor-Def, sondern ein Platzhalter für Speziallogik im Präprozessor. Den kann man nicht umdefinieren oder auf Existenz prüfen, der Syntax ergäbe überhaupt keinen Sinn.

Es scheint wirklich ein Compilerbug zu sein. Damit bleibt Dir nur der Workaround. Wir benutzen bei uns z.B. auch __LINE__ in diversen Makros, aber wir haben seit eh und je schon auf "Edit And Continue"-Debugging verzichten müssen... frag mich mal, warum. Ist schon ein paar Jahre her, aber damals führte da auch kein Weg mehr rein, außer halt auf normales Debug-Format umzuschalten. Und seitdem leben wir damit.

[kimmi]

Ich hatte schon Compiler, da half das __LINE__ definieren, weil der das __LINE__ Makro nicht kannte. Bei den Fällen hat's geholfen, ist zugegebenermaßen aber schon 3-4 Jahre her.
Aber wenn es ein bekanntes Problem ist, kann man ja auf Lösung seitens MS hoffen, die Hoffnung stirbt ja bekanntermaßen zuletzt :-).

Gruß Kimmi