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!

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

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.

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.

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.

[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.

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.

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.

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).

Jo, ist so. Interesiert keine sau

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