In welcher Methode bin ich?

[negaH]

@Sirius, ja das ist schon kompliziert besonders weil die Addresse an der die Exception ausgelösst wurde durch Delphi manches mal falsch berechnet wird, statt +4 Offset mit +5 Offset.

Am sichersten ist die Methode der JCL, auch wenn sie sagen wir mal von Hinten durch die Brust in's Auge ist. Borland hätte einfach seine vom Turbo Debugger bekannten TD Files als eigenes Segment weiterhin in die EXE einlinken lassen sollen. Leider hat Borland dieses sehr gute Features (zu DOS Zeiten einfach spitze) nicht konsequent weiterverfolgt. Mit der Übernahme des Intel Compilers ab Version 5 glaube ich hat sich das eh erledigt.

Gruß hagen

[Olli]

Tscha, da sieht man doch wiedermal die Vorteile eines Präprozessors


... ich verbleibe mit einem herzlichen __FUNCTION__ ,

[negaH]

@Olli, das musst du mir erklären ? Was hat der Präprozessor damit zu tun, bzw. was kann er zum Problem beitragen ?

Hm, es sei denn du überschreibst den Funktionsbegriff per Präprozessor mit eigener DEFINE um zusätzliche Infos irgendwo abzulegen. Allerdings frage ich mich wie das aussehen soll, benötigt der Präprozessor doch Zugriff auf den Linker um das Namemangeling auswerten zu können. Übersehe ich da was ?

Gruß Hagen

[DGL-luke]

Der Pärprozessor ersetzt __FUNCTION__ durch einen literalen string, der der bezeichnung der aktuellen methode entspricht. D.h. globale Variable "string CurrFunc = "";", in jeder Methode "CurrFunc = __FUNCTION__", bei Exceptions o.ä. CurrFunc ausgeben.

[negaH]

haste ein Link zu einem Beispiel ?

[edit]
vergiß es, habs schon gefunden. Man lernt nie aus.

Wobei das ja nicht zwangsläufig einen Präprozessor benötigt. Ein Compiler-Magic in Delphi würde ja auch gehen, wenn wir die Sourcen von Borland bekämen
[/edit]

Gruß hagen

[Olli]

Bsp. mein DDKWizard:

Code:

#if DBG
   #ifdef ADVANCED_DEBUG
   #define DebugPrint DbgPrint("[%s] %s (line: %d)\n", __##FILE##__, __##FUNCTION##__, __##LINE##__); DbgPrint
   #else
   #define DebugPrint DbgPrint
   #endif
#else
#define DebugPrint /##/DbgPrint
#endif

Was macht das (Annahme ADVANCED_DEBUG=1 und DBG=1)? Bei jeder Erwaehnung von "DebugPrint(parameter)" wird ein DbgPrint davorgestellt, weshalb es nach dem Einfuegen so aussieht:

Code:

DbgPrint("[%s] %s (line: %d)\n", __FILE__, __FUNCTION__, __LINE__); DbgPrint(parameter)

Somit wird das beim eigentlichen finalen Durchlauf des Praeprozessors als, bspw.:

Code:

DbgPrint("[%s] %s (line: %d)\n", "bla.cpp", "CMeineKlasse::MeineMethode", 37); DbgPrint(parameter)

... interpretiert.

Ziemlich bequem


... dank Praeprozessor leiste ich mir sowas dann auch nur im Debug-Build, womit die Performanceeinbussen auch nicht spuerbar sind, der Nutzen beim Debuggen allerdings schon.

[negaH]

Mittlerweile klar, nächstes mal bitte nicht so trödeln (habe ich dich zu so später Zeit aus der Kiste geholt? bin beim Warten auf deine Antwort fast eingepennt )

Allerdings bin ich mir noch nicht ganz im klaren ob das der Präprozessor macht oder der Compiler.
Die http://www.cs.cmu.edu/cgi-bin/info2www?(gcc.info)Function%20Names behaupten das der Compiler das macht.
Ok, macht aber keinen großen Unterschied für mich ob der Spaten aus Plastik oder Stahl ist, hauptsache er gräbt
Ich arbeite nun schon einige Zeit mit C und ich kannte eben diese Direktiven noch nicht, deshalb meine verdutzte Frage.

Gruß Hagen

[Olli]

Zitat von negaH:

Ok, macht aber keinen großen Unterschied für mich ob der Spaten aus Plastik oder Stahl ist, hauptsache er gräbt

Waere tatseachlich egal. Ich benutzte es bisher nur als Praeprozessor-Symbol und in meinen C-Buechern war es auch als solches ausgegeben.


Einerlei. Nein, hast mich nicht geweckt. Da Island, 2 Stunden Zeitverschiebung. Hier ist's gerade ~0:00 wenn ich das abschicke.

[Dezipaitor]

Zitat von Olli:

Zitat von negaH:

Ok, macht aber keinen großen Unterschied für mich ob der Spaten aus Plastik oder Stahl ist, hauptsache er gräbt

Waere tatseachlich egal. Ich benutzte es bisher nur als Praeprozessor-Symbol und in meinen C-Buechern war es auch als solches ausgegeben.

Mit einem Spaten aus Plastik hat man jedoch nur kurze Zeit freude oder bei leichtem Sand. Tief wird man nicht kommen

[sirius]

Zitat von negaH:

@Sirius, ja das ist schon kompliziert besonders weil die Addresse an der die Exception ausgelösst wurde durch Delphi manches mal falsch berechnet wird, statt +4 Offset mit +5 Offset.

Das ist mir noch nicht aufgefallen. Wo denn? Der nimmt doch einfach die Rücksprungadresse nach "Raise" (bzw. RaiseExcept).
Mein größtest Problem sind eher HandleAnyException und wo self liegt. Aber wenn man jetzt in den Methoden anfängt extra Infos zu hinterlegen, dann kann man doch auch gleich an die Exception-Klasse eigene Eigenschaften mitgeben.


(Unter TP war ich noch nicht so tief in die Materie eingestiegen.)