Wieso reicht delete[] zum Löschen von Arrays?

Finnegan

SeppJ schrieb:

Beispielsweise speichern manche Implementierungen die Größe direkt vor Beginn des Bereichs. Verlass dich aber bloß nicht auf solche Hacks!

Heute, viele Jahre später kann man durchaus argumentieren, dass es schon ein "Hack" im Standard ist, dass delete[] auf magische Weise die Grösse des Arrays kennen muss

Übrigens noch ein gutes Argument für hartnäckige Standardcontainer-Verweigerer, die meinen mit solchen lowlevel-Arrays schneller zu sein:
Die benötigte Array-Grösse, um die Elemente korrekt zerstören zu können liegt bei den Standard-Containern meist auf dem "heißen" Stack und damit sehr wahrscheinlich im CPU-Cache.
Muss man diese erst vom Anfang des "toten" Nutzdaten-Speicherbereichs laden ist die Wahrscheinlichkeit höher dass sie nicht im Cache liegt und man zusätzliche CPU-Zyklen verschwendet.

Finnegan

Finnegan schrieb:

SeppJ schrieb:

Beispielsweise speichern manche Implementierungen die Größe direkt vor Beginn des Bereichs. Verlass dich aber bloß nicht auf solche Hacks!

Heute, viele Jahre später kann man durchaus argumentieren, dass es schon ein "Hack" im Standard ist, dass delete[] auf magische Weise die Grösse des Arrays kennen muss

Warum?

manni66 schrieb:

Finnegan schrieb:

SeppJ schrieb:

Beispielsweise speichern manche Implementierungen die Größe direkt vor Beginn des Bereichs. Verlass dich aber bloß nicht auf solche Hacks!

Heute, viele Jahre später kann man durchaus argumentieren, dass es schon ein "Hack" im Standard ist, dass delete[] auf magische Weise die Grösse des Arrays kennen muss

Warum?

Darum.

EOP

SeppJ schrieb:

Und falls du es nicht mitbekommen haben solltest: In C++ sollte es niemals vorkommen, dass du new/delete in Anwendungscode hast.

Pah, wenn ich es für notwendig erachte, benutze ich es immer.
Wieso nicht, wenn man weiß damit umzugehen?

theta

EOP schrieb:

SeppJ schrieb:

Und falls du es nicht mitbekommen haben solltest: In C++ sollte es niemals vorkommen, dass du new/delete in Anwendungscode hast.

Pah, wenn ich es für notwendig erachte, benutze ich es immer.
Wieso nicht, wenn man weiß damit umzugehen?

Finnegan

manni66 schrieb:

Finnegan schrieb:

Heute, viele Jahre später kann man durchaus argumentieren, dass es schon ein "Hack" im Standard ist, dass delete[] auf magische Weise die Grösse des Arrays kennen muss

Warum?

Ich empfinde es schon als etwas "hackig" alles durch ein void* -Interface ohne Typ-, Größen- oder Alignment-Informationen zu stopfen,
so dass Implementationen selbst schauen müssen, wo sie die Informationen her bekommen, und dann zu solchen "Tricks" greifen, wie die Größe
des Arrays vor den Nutzdaten zu speichern. Dass da durchaus was dran ist, sieht man u.a. auch an den neuen Signaturen, die delete und delete[]
mit C++14/17 spendiert bekommen. Damals hat man sich einfach noch zu sehr an purem malloc / free orientiert.

EOP

theta schrieb:

Jetzt mal nicht frech werden, junger Mann.

EOP

Wie mach ich denn das schlauer? Mit einem Container? Wenn ich einen will wende ich mich an Hanjin, und die sind mit über 5 Mrd. auch pleite gegangen:

// keywords
	KeyWordsData *keywords_data = new KeyWordsData;
	if( keywords_data )
	{
		//keywords_data->fail_keywords = thePrefs.;
		keywords_data->success_keywords = new CStringA( thePrefs.success_kw_edit_ascii );
	}

	// send new data to the thread
	if( !::PostThreadMessage(threadID, UWM_SETTINGS_AND_KEYWORDS_DATA, (WPARAM)settings_data, (LPARAM)keywords_data) )
	{ /* failed */
		//TRACE(_T("Image Thread 0x%02x UWM_GET_HTTP/ALL task failed\n"), m_test_thread.threadID);
		delete settings_data->proxy;
		delete settings_data;

		//delete keywords_data->fail_keywords;
		delete keywords_data->success_keywords;
		delete keywords_data;
		return( false );
	} /* failed */

Techel

Du kannst trotzdem ne Helperstruct entwerfen, ähnlich std::unique_ptr, der das ganze automatisch deleted. Das zu LPARAM etc zu casten ist zwar ziemlich genau undefiniertes verhalten, aber sollte funktionieren. Schließlich enthält dieses Object lediglich nen Zeiger auf die Daten.

Ohne dieses casten täts auch eine Liste, wobei dann lediglich ein zeiger auf das Element mitgegeben wird, was dann beim Eintreffen wieder entfernt werden kann. Könnte bei C-Verehrern allerdings auf Naserümpfen aufgrund des 'Overheads' stoßen.

happystudent

Techel schrieb:

Du kannst trotzdem ne Helperstruct entwerfen, ähnlich std::unique_ptr, der das ganze automatisch deleted.

Und wie? Das würde mich auch interessieren, hatte ziemlich das selbe Problem nämlich auch schon ein paar mal.

std::unique_ptr deleted ja einfach im destruktor, also wenn er out of scope geht... das geht in dem Fall ja nicht.

Techel schrieb:

Das zu LPARAM etc zu casten ist zwar ziemlich genau undefiniertes verhalten, aber sollte funktionieren.

Klingt nicht gerade zufriedenstellend...

EOP

Wenn PostThreadMessage scheitert ist die Vorgehensweise ja schon gezeigtt. Der Rest sollte klar sein. Delete passiert dann beim Empfänger.

happystudent

EOP schrieb:

Wenn PostThreadMessage scheitert ist die Vorgehensweise ja schon gezeigtt. Der Rest sollte klar sein.

Wenn der Rest klar ist, warum fragst du dann "Wie mach ich denn das schlauer?"

Mir ist aber auch nicht klar wie ich das gezeigte mit einem smart-pointer realisieren kann, deswegen die Frage (wie ich es mit standard new/delete mache ist klar aber darum ging es ja nicht).

hustbaer

Bei den delete Anweisungen mit -> drinnen sollte wohl klar sein wie man sie los wird: unique_ptr als Member verwenden.
Und bei den anderen beiden kann auch unique_ptr helfen: einfach statt "if Fehler -> delete" den Code zu "if Erfolg -> release" umbauen.

happystudent

hustbaer schrieb:

Bei den delete Anweisungen mit -> drinnen sollte wohl klar sein wie man sie los wird: unique_ptr als Member verwenden.
Und bei den anderen beiden kann auch unique_ptr helfen: einfach statt "if Fehler -> delete" den Code zu "if Erfolg -> release" umbauen.

Hm, release hab ich bis jetzt noch nie verwendet... scheint höchste Zeit zu werden

EOP

c

hustbaer schrieb:

Bei den delete Anweisungen mit -> drinnen sollte wohl klar sein wie man sie los wird: unique_ptr als Member verwenden.
Und bei den anderen beiden kann auch unique_ptr helfen: einfach statt "if Fehler -> delete" den Code zu "if Erfolg -> release" umbauen.

Du meinst, das funktioniert auch in einem anderen thread.
Sorry for hijacking this thread. Wäre eigentlich ein MFC-Thema.

SeppJ schrieb:

Und falls du es nicht mitbekommen haben solltest: In C++ sollte es niemals vorkommen, dass du new/delete in Anwendungscode hast.

wieso? Wenn ich mir einen Kugelschreiber kaufe, werfe ich deshalb doch auch nicht alle Bleistifte weg.

Dumpfbackenhausen

SeppJ

zufallswert schrieb:

SeppJ schrieb:

Und falls du es nicht mitbekommen haben solltest: In C++ sollte es niemals vorkommen, dass du new/delete in Anwendungscode hast.

wieso? Wenn ich mir einen Kugelschreiber kaufe, werfe ich deshalb doch auch nicht alle Bleistifte weg.

Besserer Vergleich wäre: Wenn du einen Füller hast, steckt du nicht deinen Finger in die Tinte und malst damit auf dem Papier herum.

hustbaer

EOP schrieb:

c

hustbaer schrieb:

Bei den delete Anweisungen mit -> drinnen sollte wohl klar sein wie man sie los wird: unique_ptr als Member verwenden.
Und bei den anderen beiden kann auch unique_ptr helfen: einfach statt "if Fehler -> delete" den Code zu "if Erfolg -> release" umbauen.

Du meinst, das funktioniert auch in einem anderen thread.
Sorry for hijacking this thread. Wäre eigentlich ein MFC-Thema.

Ja klar funktioniert das auch in einem anderen Fred.
Der unique_ptr macht ja im Endeffekt auch nix anderes als ein delete - nur halt automatisch, in dem Fall wenn das "äussere" Objekt welches den unique_ptr als Member hat gelöscht wird.
Der einzige Unterschied ist da echt dass du das delete nicht mehr selbst hinschreiben musst.

Nimm dir aber auch den anderen Teil zu Herzen. Also das Muster
- Verpacken in Smart-Pointer von Anfang an
- Alles fertig zusammenbauen
- Übergabe irgendwohin, über einen Kanal wo man nicht direkt den Smart-Pointer transportieren kann
- Smart-Pointer Release falls Übergabe funktioniert hat

Das ist zwar auch nicht super-schön, weil man eben manuell mit release rumfummeln muss... aber IMO immer noch viel besser als im Fehlerfall selbst delete aufzurufen. Ownership sollte immer klar und automatisch geregelt sein, ab dem Zeitpunkt wo ein Objekt existiert. Also ab dem new oder woher auch immer man das Objekt bekommt. Wenn man dazwischen unschöne Kanäle wie PostMessage verwenden muss, dann geht's halt nicht anders (*), aber davor und danach immer
Smart-Pointer.

*: Natürlich geht es auch bei PostMessage anders. Beispielsweise indem man die Message irgendwo in ne Membervariable steckt (evtl. auch ne Liste/Queue falls nötig) und dann per PostMessage bloss noch die Benachrichtigung verschickt dass es was in der Membervariable/Queue abzuholen gibt. (**) Gibt aber natürlich Fälle wo sowas nicht geht bzw. nicht praktikabel ist. Und in diesen Fällen kann (und sollte) man die Bereiche wo man keinen automatischen "Resourcenhalter" hat immer noch so weit wie möglich minimieren.

**: OK, das hat Techel ja schon vorgeschlagen.

ps: Wozu überhaupt nen CStringA -Zeiger als Member und nicht direkt den CStringA ? Und... warum man besser "if erfolg -> release" statt "if fehler -> delete" macht, sollte dann auch klar sein: Weil beim new CStringA (siehe "alles fertig zusammenbauen" oben) ne Exception rausfliegen könnte. Was natürlich auch so bleibt wenn der CStringA direkt als Member drinnen steckt - der muss seinen Speicher beim Assignment ja auch irgendwoher nehmen.

EOP

Danke für die Antwort, hustbaer.
Ich muss mir das aber noch mindestens einmal durchlesen.
Im Moment hab ich sowieso nur VS 2005 zur Verfügung.