ich hab mal wieder so ne naive Vorstellung, nach der jede Klasse eine Logausgabe in ihrem Destruktor machen soll. Dazu möchte ich auch gern die Makros

__FILE__, __func__, __LINE__

benutzen.

Die Idee war, die eigentliche Ausgabe in einem Destruktor einer Basisklasse zu machen und alle anderen Klassen davon ableiten zu lassen. Nun hab ich aber gelernt, dass ein übergeordneter Destruktor erst nach dem Abarbeiten des eigenen Destruktors an die Reihe kommt.
Wird denn da nicht durch den Sprung in die Basisklasse bei den Makros immer nur deren Bezug ausgegeben (also immer nur die Attribute für Zeile, Funktion und Datei dieser Basisklasse)?

Geht mein Vorhaben denn überhaupt, oder muss ich den Eintrag in jede Klasse einzeln aufnehmen?

Vielen Dank schon mal!

Ciao

Du kannst zwar nicht __FILE__ und __LINE__ des Destruktors miteinbauen, obwohl das mit üblem Getrickse auch möglich wäre.

Deine Log-Basisklasse übernimmt im Konstruktor als Parameter __FILE__ und __LINE__ und am besten noch den #CLASSNAME als String.

Du schreibst Dir dann ein Makro für den Konstruktor Deiner xy-Klasse das die Log-Basisklasse über ihren Konstruktor mit den oben angeführten Parametern intialisiert. Letzterer könnte z. B. gleich Loggen "Instanz von Klasse xy, deklariert in xy.h(Zeile 4) erstellt.".

Der Destruktor der Basisklasse loggt dann bei Aufruf, dass die Klasse zerstört wurde.

Wenn Du es geschickt machst, kannst Du diese Basisklasse sich z. B. bei einer statischen Manager-Klasse registrieren lassen, die jeder Instanz einer Klasse eine Zahl zuweist, so dass du im Log z. B. verfolgen kannst, ob alle Instanzen aus dem Speicher sind. Sollte letzteres nicht der Fall sein, könnte dieser Manager das auch noch in den Log schreiben.

Theoretisch könntest Du auch ein Instanz Makro machen. Das würde erfordern, das jede Klasse schon im Konstruktor ein paar Logging-Parameter entgegennimmt, die sie dann die Log-Basisklasse schickt. So könnte z.B. mitgeloggt werden, wo eine Instanz gebaut wird (wieder über __FILE__ etc.).

Diese Makros sollten auf jeden Fall ordentlich gebaut werden, damit Du dir nicht verbaust, Klassen mit beliebig vielen Parametern, Basisklassen, beliebigem Konstruktor-Code etc. zu deklarieren.

Wenn Du fertig bist, schick sie mir

Du kannst zwar nicht __FILE__ und __LINE__ des Destruktors miteinbauen, obwohl das mit üblem Getrickse auch möglich wäre.

Wie soll das gehen ?

DESTRUCTOR_BEGIN(klassenname)

DESTRUCTOR_END

schreibt.

Aber wenn man nicht weiß, wo der Destruktor steht, dann hat man eigentlich nähere Probleme.

Wo der Destruktor aufgerufen wird, kann man natürlich nicht loggen, falls Du das meinst. Fällt mir jedenfalls jetzt nichts zu ein.

Das sind Macros. Macros werden vom Präprozessor aufgelöst. Er weiß nichts von irgendwelchen Ableitungshierarchien. Das müsstest du schon in jede Klasse schreiben. Und ich spar mir jetzt (fast) den Kommentar, dass ich das sowieso nicht so sinnvoll finde, im Destruktor was zu loggen.

Dito. im dtor legt sich das Objekt zur Ruhe. Es ist eine sehr emotionale Phase des Objekts und sollte sich ausschließlich mit der Auflösung des Speichers befassen.
Scherz, nein das Problem des dtors ist, dass es keine Rückgabewerte gibt und man eigentlich etwas abgeschottet ist. Es kann ja sein, dass dein Logger kaputt ist (Festplatte voll, Stream unterbrochen, etc...), und du kannst darauf nicht reagieren. Da bau lieber eine Methode void terminate(), die delete this; aufruft und davor loggt.

Zu den Makros: __FILE__ und __LINE__ sind welche und werden VOR Laufzeit vom Präprozessor mit den Werten ersetzt. Also wenn du eine Basisklasse mit den Makros benutzt und meinst du kannst die vererben, dann wird __FILE__ und __LINE__ immer die gleichen Werte haben, nämlich an der Stelle im Code wo sie auch stehen auch nach der 100 Vererbungsebene

// A.h
class A : public MyDtorLogger{ };
class B : public MyDtorLogger{ };

// main.cpp
int main() {
A *a = new A;
B *b = new B;

// ...

delete a; // --> Ausgabe: Dtor of .../MyDtorLogger.cpp line 20 wurde ausgeführt

// ...
delete b; // --> Ausgabe: Dtor of .../MyDtorLogger.cpp line 20 wurde ausgeführt
}

Es kann ja sein, dass dein Logger kaputt ist (Festplatte voll, Stream unterbrochen, etc...), und du kannst darauf nicht reagieren. Da bau lieber eine Methode void terminate(), die delete this; aufruft und davor loggt.

So ein Blödsinn.
Wie willst du denn überhaupt irgendwo auf Logging-Probleme reagieren? Eine Fehlermeldung Loggen? Oder das Programm abbrechen weil nimmer geloggt werden kann? (OK, das KANN für manche Programme Sinn machen, kann man aber auch super im Dtor triggern)
Oder ne Exception werfen, den aktuellen Vorgang abbrechen, was dann erst wieder dazu führt dass alle möglichen Objekte zerstört werden?

Nene, also loggen kann man im Dtor problemlos. Denn man sollte verdammtnochmal sicherstellen, dass die Logging Funktionen nie nie nie Exceptions werfen.
(Bzw. an den nötigen Stellen Exceptions die beim Zusammenbau von Log-Messages immer mal wieder vorkommen können gefälligst zu fangen)

Achja: Fehlerbehandlung beim Loggen: ignorieren. Ich denke das hätte sich mittlerweile rumgesprochen.

PhilippHToner schrieb:

Es kann ja sein, dass dein Logger kaputt ist (Festplatte voll, Stream unterbrochen, etc...), und du kannst darauf nicht reagieren. Da bau lieber eine Methode void terminate(), die delete this; aufruft und davor loggt.

So ein Blödsinn.
Wie willst du denn überhaupt auf Logging-Probleme reagieren? Eine Fehlermeldung Loggen?

Er könnte dir n Datagramm mit "HELP" und seinen Koordinaten senden?
Vielleicht einfach der Fehlerbehandlungsstrategie nachgehen, die das Projekt vorsieht? Ich kann komplett unabhängig einen anderen Prozess starten, der sich um den Fehler kümmern soll und das aktuelle Programm soll terminieren. Der andere Prozess zeigt den Fehler z.B. in Form einer Fehlermeldung mit GUI an. Und wenn alle Stricke reißen gibt's vielleicht OS-Routinen, die sich damit besser auseinandersetzen inkl. Prozessdump oder ähnlich.

hustbaer schrieb:

PhilippHToner schrieb:

Es kann ja sein, dass dein Logger kaputt ist (Festplatte voll, Stream unterbrochen, etc...), und du kannst darauf nicht reagieren. Da bau lieber eine Methode void terminate(), die delete this; aufruft und davor loggt.

So ein Blödsinn.
Wie willst du denn überhaupt auf Logging-Probleme reagieren? Eine Fehlermeldung Loggen?

Er könnte dir n Datagramm mit "HELP" und seinen Koordinaten senden?
Vielleicht einfach der Fehlerbehandlungsstrategie nachgehen, die das Projekt vorsieht? Ich kann komplett unabhängig einen anderen Prozess starten, der sich um den Fehler kümmern soll und das aktuelle Programm soll terminieren. Der andere Prozess zeigt den Fehler z.B. in Form einer Fehlermeldung mit GUI an. Und wenn alle Stricke reißen gibt's vielleicht OS-Routinen, die sich damit besser auseinandersetzen inkl. Prozessdump oder ähnlich.

Gut.
Und genau wieso soll das jetzt nicht gehen wenn die Logging Funktionen aus einem Dtor aufgerufen werden?

Gut.
Und genau wieso soll das jetzt nicht gehen wenn die Logging Funktionen aus einem Dtor aufgerufen werden?

Ganz ehrlich, das ist denk ich Geschmackssache wie es geimplt wird. Ich für meinen Teil finde, dass der Dtor wie gesagt alles was sich das Objekt "geliehen" hat, sei es Speicher oder öffene Dateien, freigibt und schließt. Wenn hier ein Fehler auftritt, dann sei es so, aber was soll schon im Dtor passieren? Wenn man hier vernüftig z.B. die Pointer nach dem Löschen NULL setzt und vor dem Löschen prüft sollte eigentlich alles getuned sein. Wenn eine Datei, wie es 314159 gesagt hat sich nicht mehr schließen lässt, dann halt nicht, ist nur die nette Geste. Aber Datei öffnen ist schon wieder schlecht finde ist. Ich würde halt niemals in einen Dtor eine weitere Verzweigung sonstwohin einbauen, also auch kein Loggen. Wer Lust hat es dennoch zu, who cares...