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

hustbaer

Bidde bidde.

Naja, ob jetzt std::unique_ptr , boost::scoped_ptr oder boost::movelib::unique_ptr macht diesbezüglich keinen Unterschied, kannste alle drei nutzen - bzw. mit VS 2005 halt nur die letzten beiden.

Und gegenüber manuellem delete wäre sogar std::auto_ptr ein Fortschritt. Wobei es natürlich kaum Sinn machen wird std::auto_ptr zu verwwenden wenn man auch die Boost verwenden kann.
(Und wenn du keine Boost hast, dann ist so ne minimale scoped_ptr Implementierung auch keine Hexerei - das sind ein paar ziemlich unspannende Zeilen mit wenig Fehlerpotential.)

knivil

Ich habe eine Bekannte, deren Eltern sehr um die Sicherheit ihrer Tochter besorgt waren und sie auch entsprechend erzogen. Leider kann besagte Tochter nicht die Weihnachtskerzen mit Feuerzeug oder Streichhoelzer anzuenden, da sie ungeuebt und sehr aengstlich im Umgang mit Feuer ist. Das Dilemma von brauchbaren Dingen ist, dass sie im gleichen Sinne missbraucht werden koennen. Wenn sie unnuetzt waeren, so werden sie auch nicht missbraucht. Gleiches trifft fuer Messer, Gabel, Schere, Licht zu. Ich fuer meinen Teil bin schon erwachsen.

Angst vor new/delete ist fehl am Platz, auch das dogmatische warnen. Dudududu, so nicht ... Leider spricht niemand ueber die Nachteile oder den Missbrauch von smart Pointern. Smart Pointer sind Implementationsdetail (siehe Stroustrup-Videos). Leider tendieren sie, uebermaessig intensiv benutzt zu werden, so dass dieses Detail nach aussen getragen wird, insbesondere bei std::shared_ptr zu beobachten. Wenn der ganze Code mit shared_ptr uebersaeht ist, dann hat man garantiert was falsch gemacht. Leider wird genau dieses Muster hier empfohlen. Ein Kollega meinte: We do not need smart pointer but we need smart developers. Ich wundere mich sowieso, wie wir zum Mond fliegen konnten ohne smart Pointer. Kaum etwas aus pre-C++11 ist ungueltig geworden.

Wo werden von mir haupsaechlich rohe Zeiger benutzt: DLL-Grenzen. Z.B. Arrays werden als Zeiger + Anzahl der Elemente uebergeben. Alle Klassen meist durch Pimpl-Idiom gekapselt (roher Zeiger, kein unique_ptr). Auch der Verzicht auf Klassen der Laufzeitumgebung hat mir schon viel Aerger erspart, genauso wie virtual.

Einige Kommentare:

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.

loled really hard. delete von Elementen als Performanceargument ins Feld fuehren. Nein, das liegt nicht im kritischen Code.

zu solchen "Tricks" greifen, wie die Größe des Arrays vor den Nutzdaten zu speichern

Das ist kein schmutziger Trick sondern ein Implementationsdetail. Auch https://www.youtube.com/watch?v=vElZc6zSIXM sind keine schmutzigen Tricks, sie wissen nur, wie mit dem Messer, Gabel, Schere, Licht umzugehen ist. Ach, schaue bitte nicht in die Sourcen der C++-Standardbibliothek, alles schmutzige Tricks ...

Wie mach ich denn das schlauer?

OMG ... Benutze nicht die Messagequeue des Fensters. Weil ... reasons ...

You'll end up with a unresponsive GUI. Our company has a lot of experience with exactly this failed designed technique

Quelle: http://stackoverflow.com/questions/123323/how-deep-is-the-win32-message-queue

auto_ptr

Das wird seit jeher totgeschwiegen, genauso wie vector<bool>.

hustbaer

knivil schrieb:

Angst vor new/delete ist fehl am Platz, auch das dogmatische warnen.

Falsch und falsch.

knivil schrieb:

Dudududu, so nicht ... Leider spricht niemand ueber die Nachteile oder den Missbrauch von smart Pointern.

Doch, eigentlich recht viele Leute. Unter anderem du jetzt - bloss leider nicht sachlich.

Und auf den Rest im Detail einzugehen ist mir ehrlich gesagt zu doof.

Smart Pointer sind Implementationsdetail (siehe Stroustrup-Videos). Leider tendieren sie, uebermaessig intensiv benutzt zu werden, so dass dieses Detail nach aussen getragen wird, insbesondere bei std::shared_ptr zu beobachten.

Beachte, dass ein Smart Pointer ohne spezialisierten Deleter-Vorgang kein Implementationsdetail zum Vorschein bringt.

Das ist nämlich das, was die meisten brauchen.

Ist auch viel sicherer gerüstet gegen Fehler usw. Scope raus -> Freigeben.

knivil

hustbaer schrieb:

knivil schrieb:

Angst vor new/delete ist fehl am Platz, auch das dogmatische warnen.

Falsch und falsch.

knivil schrieb:

Dudududu, so nicht ... Leider spricht niemand ueber die Nachteile oder den Missbrauch von smart Pointern.

Doch, eigentlich recht viele Leute. Unter anderem du jetzt - bloss leider nicht sachlich.

Und auf den Rest im Detail einzugehen ist mir ehrlich gesagt zu doof.

Ich weiss, wer argumentiert, hat verloren. Du hast gewonnen.

Ist auch viel sicherer gerüstet gegen Fehler usw. Scope raus -> Freigeben.

Ich habe explizit shared_ptr angefuehrt.

knivil schrieb:

Ich habe explizit shared_ptr angefuehrt.

Wenn du keinen Reference counting brauchst, brauchst du den auch nicht.

hustbaer

knivil schrieb:

Ich weiss, wer argumentiert, hat verloren. Du hast gewonnen.

Naja, du hast ja eben gerade nicht argumentiert. Zumindest nicht fair oder sinnvoll. Du hast (unter anderem) gestrohmannt. Die anderen Fallacies suche ich dir vielleicht raus wenn du das zugegeben hast. Davor gilt wiederrum: ist mir zu doof.

knivil schrieb:

Ist auch viel sicherer gerüstet gegen Fehler usw. Scope raus -> Freigeben.

Ich habe explizit shared_ptr angefuehrt.

Genau. shared_ptr. Strohmann.

EOP

knivil schrieb:

Wie mach ich denn das schlauer?

OMG ... Benutze nicht die Messagequeue des Fensters. Weil ... reasons ...

Um das nochmal genau zu erklären:
Ich sende Daten an threads - können auch hundert und mehr gleichzeitig sein. Die haben kein Fenster.
Die threads senden dann die Daten/Ergebnisse auf die gleiche Weise zurück an den Ursprung - diesmal ist es wirklich ein Fenster/Dialog/PropertySheet - wo das Ganze dann gequeued und ausgewertet wird.
Klappt mit new/delete auch hervorragend. Die Frage war nur so aus Neugier.

knivil

Naja, du hast ja eben gerade nicht argumentiert

Nun der gesamte erste Absatz ist ein Argument gegen dogmatischen Umgang mit smart pointer, gegen "Verteufelung" von rohen besitzenden Zeigern mit entsprechenden Folgen als Gleichnis.

SeppJ

knivil schrieb:

Naja, du hast ja eben gerade nicht argumentiert

Nun der gesamte erste Absatz ist ein Argument gegen dogmatischen Umgang mit smart pointer, gegen "Verteufelung" von rohen besitzenden Zeigern mit entsprechenden Folgen als Gleichnis.

Das ist aber kein Argument gewesen, sondern eine Anekdote zu einem komplett anderen Thema.