delete [] p ?
-
[][][] schrieb:
CStoll schrieb:
Ein einzelnes Bit kann nicht alleine untergebracht werden, also mußt du mindestens ein Byte für die Information "ich bin ein Array" veranschlagen - aus Padding-Gründen meist noch mehr. Und dieses mußt du so anlegen, daß es nicht mit irgendwelchen Nutz-Informationen kollidiert.
praktisch wirst du auf den meisten plattformen für dieses eine bit den platz finden. gibt es überhaupt eine plattform, auf der ein new[std::numeric_limits<size_t>::max() >> 1] nicht fehlschlägt?e
Und wo soll dieser Platz deiner Meinung nach sein? Im allokierten Objekt geht nicht (schließlich weißt du nicht, ob und welche Bereiche des Objekts ungenutzt sind), dahinter auch nicht (bei Arrays wärst du dann im nächsten Objekt), also bleibt nur davor - und da mußt du darauf achten, daß du die Adressen "richtig" im Speicher ausrichtest, sonst wird es wirlich langsam.
das ist doch praktisch überhaupt nicht relevant. wie oft legst du so kleine objekte mit new an, dass der entstehende overhead für die anzahl überhaupt ins gewicht fällt?
Zum Glück entscheidest nicht du, was relevant ist und was nicht. Das hängt immer von der Anwendung ab (und z.B. bei Listen oder Bäumen ist der Overhead schon erheblich, bei jedem Knoten noch die Anzahl 1 zu speichern).
Wenn dir die genannten Gründe nicht gut genug sind, bist du selber Schuld
Mir reichen sie.vielleicht ist mir ist konsistenz und sicherer code wichtiger als dir.
Konsistenz erreichst du aber eher damit, daß du auf nackte Speicher-Verwaltung verzichtest - nimm lieber std::vector<> und Kollegen, die kapseln solche Probleme für dich
-
CStoll schrieb:
Und wo soll dieser Platz deiner Meinung nach sein?
hab doch schon ein beispiel gebracht. im obersten bit der allokationsgröße wäre auf den meisten plattformen eine möglichkeit.
Konsistenz erreichst du aber eher damit, daß du auf nackte Speicher-Verwaltung verzichtest - nimm lieber std::vector<> und Kollegen, die kapseln solche Probleme für dich
es geht aber nicht um die standardbibliothek sondern um delete[]. wenn ich ausschließlich delete[] benutzen würde (bescheuert aber legitim), wäre das konsistent.
wenn ich einen smartpointer schreiben könnte, der ohne einschränkungen sowohl für einzelne objekte als auch für arrays funktionieren würde, dann wäre das konsistent. geht aber ned, weil ich blöderweise zwischen delete und delete[] unterscheiden muss.
-
[][] schrieb:
CStoll schrieb:
Und wo soll dieser Platz deiner Meinung nach sein?
hab doch schon ein beispiel gebracht. im obersten bit der allokationsgröße wäre auf den meisten plattformen eine möglichkeit.
Ja, jetzt brauchst du nur noch eine plattformübergreifende Möglichkeit, da ranzukommen
(wo malloc/free sich die Größe des Blocks merken, ist nicht standardisiert)
-
[][][][][][], Du ignorierst geflissen die Kern-Philosophie von C++: „Don't pay for what you don't use.“ Ganz egal, wie gering das zusätzliche Overhead wäre, es ist inakzeptabel. Aus genau demselben Grund ist ja z.B. auch der Destruktor einer Klasse nicht standardmäßig virtuell, obwohl das viele Sachen erleichtern würde.
-
CStoll schrieb:
Ja, jetzt brauchst du nur noch eine plattformübergreifende Möglichkeit, da ranzukommen
(wo malloc/free sich die Größe des Blocks merken, ist nicht standardisiert)uff. ich mag mich hier echt nicht um jedes einzelne bit zanken. ich bin mir sicher, dass irgendein cleverer bursche schon einen mechanismus dafür gefunden hätte, die plattform für die verwaltung der objektanzahl zuständig zu machen und die damit die möglichkeit hätte, sie sehr effizient zu verwalten.
und ich bin mir auch sicher, dass sich kein programmierer darüber beschwert hätte. und sich damit viele tausend stunden debugging hätten einsparen lassen.
in anderen sprachen hat man deshalb so späße wie garbage collectors eingebaut, damit man sich ums freigeben nicht mehr explizit kümmern muss.
-
Ja, es gibt etwa ein halbes Dutzend mögliche Strategien, die Größe eines allokierten Speicherblocks zu speichern (grob geschätzt). Und in der Regel sind die new/delete eines Compilers auch darauf ausgerichtet, mit dessen Speicherverwaltung zurechtzukommen (wobei nicht einmal festgelegt ist, daß new intern auf malloc() aufbauen muß). Der Kernpunkt dieser Diskussion ist, daß jedes System hinter den Kulissen sein eigenes Süppchen kochen kann - und wenn du dich nicht auf eins festlegen willst, mußt du alle Möglichkeiten kennen.
-
Konrad Rudolph schrieb:
[][][][][][], Du ignorierst geflissen die Kern-Philosophie von C++: „Don't pay for what you don't use.“
stimmt. aber fehlersuche wegen falschem delete kostet auch etwas, wenn auch nicht rechenzeit oder speicherplatz. und den extracode, den man dann und wann wegen der unterscheidung schreiben muss, gibts auch nicht kostenlos.
Ganz egal, wie gering das zusätzliche Overhead wäre, es ist inakzeptabel. Aus genau demselben Grund ist ja z.B. auch der Destruktor einer Klasse nicht standardmäßig virtuell, obwohl das viele Sachen erleichtern würde.
ein unterschied ist: für virtuelle destruktoren musste kein neues keyword eingeführt werden (ich sehe delete[] mal als eigenes keyword). der kosten-/nutzenfaktor ist günstiger.
-
und sagt doch mal ehrlich: wenn ihr eine entsprechende programmiersprache entwerfen würdet, würdet ihr wirklich eine unterscheidung zwischen delete und delete[] vorsehen? vielleicht könnt ihr dabei mal versuchen zu vergessen, dass ihr "c++-geschädigt" seid.
-
[][][] schrieb:
und sagt doch mal ehrlich: wenn ihr eine entsprechende programmiersprache entwerfen würdet, würdet ihr wirklich eine unterscheidung zwischen delete und delete[] vorsehen?
Nein, natürlich nicht. Aber ich würde auch nicht auf C-Kompatibilität achten und aus diesem Grund überhaupt gar nicht erst diese dummen C-Array-Konstrukte erlauben.
Wie es der Zufall so will arbeite ich tatsächlich am Design einer Programmiersprache, viele ähnliche Konzepte wie C++ verfolgt. C-ähnliche Arrays gibt es hier nicht. Es gibt lediglich rohen Speicher, auf dem man tun und lassen kann, was man will – ähnlich dem C++-Allokator-Konzept.
-
[][][] schrieb:
und sagt doch mal ehrlich: wenn ihr eine entsprechende programmiersprache entwerfen würdet, würdet ihr wirklich eine unterscheidung zwischen delete und delete[] vorsehen?
Ja, wuerde ich sofort, wenn ich auf die dumme Idee kaeme, in einer objektorientierten Sprache Arrays zu erlauben, die keine eigenen Objekte sind. Wie KR schon sagt, ist die ganze Problematik aus den Zugestaendnissen an das laestige C-Erbe entstanden.