Warum übheraupt noch deinitialisieren?

JWolfram

Hallo,

die Literatur predigt z.B. Gerätekontexte beim Beenden des Programms zu deinitalisieren.
Aber ist es denn nicht so, dass Windows (NT/2000/XP) dies bereits zuverlässig von selbst macht?
Ich kann jedenfalls keinen Unterschied entdecken.

Oder gibt es doch mögliche Gründe diesen Aufwand noch zu betreiben?

Vielen Dank für Infos!

DocJunioR

Tjoo,
meine Mutter hat mein Zimmer auch immer aufgeräumt, wenn ich lange genug zu faul war...
Nur hab ich dann nichts mehr wiedergefunden....

Es geht einfach um's Prinzip. Was man nutzt, sollte man auch wieder wegräumen.

JWolfram

Währe toll wenn mir jemand den praktischen Nutzen and irgend einen Beispiel erläutern?

thenoname

Diese Frage ist durchaus berrechtigt.
Ich frage mich auch folgendes:

Wandlung von CString in LPTSTR

CString a = "hallo welt";
int nLen = a.GetLength();
LPTSTR lp = a.GetBuffer(nLen);
a.ReleaseBuffer();

Wenn ich in einer Funktion bin, wird nach dem Beenden
sowieso alles verworfen, also warum den ReleaseBuffer ??

Nachdem ich erfahren habe, das Delphi die Release sogar automatisch
nach dem Beenden übernimmt, frage ich mich, warum das VC++ nicht kann.

ness

zum Thema allgemein:
Es giebt viele neue sachen, die codeverkürzungen zulassen, z.B.: return [...] am ende einer Funktion, kann man bei vielen Compilern inzwischen weglassen...
Wenn wer das tut meckern aber sicherlich einige! Ich denke, das sich irgendwann (hoffentlich bald) eine neue Generation von Programmierern herauskristallisieren wird, die den gebotenen Komfort schätzen und nutzen.

Christoph

thenoname schrieb:

CString a = "hallo welt";
int nLen = a.GetLength();
LPTSTR lp = a.GetBuffer(nLen);
a.ReleaseBuffer();

C++ kennt Destruktoren. Wenn CString diese nicht benutzt, liegt diese Verhaltensweise wohl an CString.
std::string beispielsweise benötigt keinen relase()-Aufruf nach string::c_str().

Die WinAPI verlangt Release-Aufrufe, also muss man sie benutzen. Wenn sie nicht mehr benötigt würden, würden in der Doku entsprechende Hinweise stehen ("überflüssig" o.ä.).
In C++ würde man diese Release-Aufrufe natürlich mit Destruktoren kapseln.

ness schrieb:

return [...] am ende einer Funktion, kann man bei vielen Compilern inzwischen weglassen...

Das Komma war wohl ein Tippfehler.
return wegzulassen ist ziemlicher Blödsinn und nur bei main() erlaubt und sinnvoll. Ansonsten deklariert man die betreffende Funktion void.

thenoname

cd9000 schrieb:

Wenn sie nicht mehr benötigt würden, würden in der Doku entsprechende Hinweise stehen ("überflüssig" o.ä.).

Dazu fällt mir der passende Ausspruch der MSDN ein:

Funktion: Release
may be useful for diagnostics or testing

Das mit dem Destruktor hatte ich hier schon mal erwähnt. Irgendwie macht
der Destruktor beim OnClose nicht automatisch alle Objekte, Interfaces usw.
zu. Wie gesagt, in Delphi werden die API Release methoden umbenannt in
_release und vom Programmierer somit ferngehlten. Am Schluss macht der Destruktor
alle _release Aufrufe und gut ist.

Christoph

thenoname schrieb:

[Delphi hält release() vom Programmierer fern]

Das ist in C++ ebenfalls ohne Probleme möglich, wenn man nicht gerade eine Klassenbibliothek benutzt, die auf manuelle Speicherfreigabe besteht.

peterchen

Vertrag vs. Implementation:

Der "Vertrag" (also die zugehörige Dokumentation - MSDN) fordert von dir, den DC wieder freizugeben.

Die aktuelle Implementation könnte dich für das nicht-releasen mit Rosenblättern überhäufen, und du wärest trotzdem falsch, da Sich die Implementation jederzeit ändern kann.

Daß Microsoft andererseits zusichert, daß dein DC trotzdem freigegeben wird ist ein Vertrag mit mir, nicht mit dir: Sie tun alles, was sie können daß meine Nutzer kein Problem mit meinem Programm haben, egal wie schlecht dein Programm ist.

peterchen

@thenoname: - bzgl. ReleaseBuffer:

GetBuffer gibt deaktiviert die interne Referenzzählung, um dir schreibenden Zugriff auf das String-Buffer zu gewährleisten. Mit ReleaseBuffer zeigst du an, daß du dies nicht mehr benötigst, und die automatische Speicherverwaltung wieder aktiviert werden soll.

[edit]
Der Speicher wird vom Destruktor freigegeben, auch wenn du ReleaseBuffer "vergißt".

Das läßt sich sicherlich auch anderweitig bewerkstelligen, die Frage ist nur: zu welchen Implementations- und Performance-Kosten? Wenn du permanent schreibenden Zugriff brauchst, kommst du mit einem anderen Datentyp (z.B. vector<TCHAR>) oft besser.

CMatt

JWolfram schrieb:

Hallo,

die Literatur predigt z.B. Gerätekontexte beim Beenden des Programms zu deinitalisieren.
Aber ist es denn nicht so, dass Windows (NT/2000/XP) dies bereits zuverlässig von selbst macht?

Jo, ist so. Interesiert keine sau ob du in der WM_DESTROY dein zeugs wieder freigibst (ausser denen die deinen programmierstil bewerten).

peterchen

Jo, ist so. Interesiert keine sau

Zum Glück werden Code Reviews nicht von Säuen durchgeführt

Normalerweise muss man ja auch Resourcen schon früher freigeben als bei Programmende.

geeky

win2k/xp mag ja selber aufräumen, aber z.B. mit GDI-Resourcen unter Win9x wird man schnell seine Freude kriegen wenn man erzeugte GDI-Objekte nicht wieder freigibt...