Was kommt zuerst: Destruktor oder Deallokation ?

Arcoth schrieb:

Dieses Zitat ist defekt.

Kauf dir ein Argument. Du hast das System durchbrochen, jetzt müsste der Thread eigentlich von der Forenpolizei geschlossen werden.

hustbaer schrieb:

tkausl schrieb:

Prinzipiell ist der DTor auch "nur" eine normale Methode, da passiert keine Magic im hintergrund.

Ja.

Nein.

hustbaer schrieb:

Arcoth schrieb:

hustbaer schrieb:

@Arcoth
Wie lautet denn das nicht-kaputte Zitat?

Ein trivialer Destruktor sollte ein Objekt (konzeptionell) nicht zerstören. Es ist ein no-op.

Das könnte man so definieren, ja. Ich verstehe bloss den Nutzen nicht. Welchen (realen) Vorteil hätte man dadurch?

Z.B: Ein unsigned char-Objekt ist immer gültig?

hustbaer

argumentclinic schrieb:

hustbaer schrieb:

tkausl schrieb:

Prinzipiell ist der DTor auch "nur" eine normale Methode, da passiert keine Magic im hintergrund.

Ja.

Nein.

Weil?

argumentclinic schrieb:

hustbaer schrieb:

Arcoth schrieb:

hustbaer schrieb:

@Arcoth
Wie lautet denn das nicht-kaputte Zitat?

Ein trivialer Destruktor sollte ein Objekt (konzeptionell) nicht zerstören. Es ist ein no-op.

Das könnte man so definieren, ja. Ich verstehe bloss den Nutzen nicht. Welchen (realen) Vorteil hätte man dadurch?

Z.B: Ein unsigned char-Objekt ist immer gültig?

Für char, signed char und unsigned char gibt es sowieso eigene Regeln. Du darfst eine Speicherstelle jederzeit als (signed/unsigned) char ansprechen, auch wenn da nie ein (signed/unsigned) char reinkonstruiert wurde.
Dass ein unsigned char-Objekt ist immer gültig ist ändert sich also nicht, egal ob man definiert dass ein trivialer Destruktor ein Objekt zerstört oder nicht.

hustbaer

ps:

Arcoth schrieb:

Edit:

BTW: Hast du zufällig nen Link zum aktuellen Working-Draft parat?

http://open-std.org/JTC1/SC22/WG21/docs/papers/2015/n4527.pdf

Danke

Columbo

hustbaer schrieb:

Das könnte man so definieren, ja. Ich verstehe bloss den Nutzen nicht. Welchen (realen) Vorteil hätte man dadurch?

Ich kann keinen erkennen. Jedenfalls ist die Ideologie des Standards die, das e.g. PODs genau wie fundamentale Typen nicht durch einen (Pseudo-)Destruktoraufruf zerstört werden können. Sie sind einfach ein paar zusammenhängende Bytes, die vom abstrakten Modell des Konstruktors/Destruktors verschont sind.

Wie auch immer, die Definition von object lifetime ist - wie bereits erwähnt - gerade völlig schrott und vage, deswegen habe ich auch nicht wirklich Lust darüber zu diskutieren solange kein entsprechendes Paper vorliegt, das eine sinnvolle resolution parat hat.

Nope.

Mir ging es darum, dass du eine Zeile in einem simplen Pseudocode gezeigt hast, die sonst nur in e.g. std::allocator<>::construct vorhanden ist. §3.8 castet this auch nicht gleich nach void* . Musst doch nicht immer gleich deine volle Generizitätskanone raushauen.

@hustbaer: Da gibt's nix zu danken. Einfach bei isocpp.org nach links gucken. Oder im repo von cppdraft schauen.

Columbo

Du darfst eine Speicherstelle jederzeit als (signed/unsigned) char ansprechen,

unsigned char und char , nicht aber signed char .

hustbaer

Arcoth schrieb:

Du darfst eine Speicherstelle jederzeit als (signed/unsigned) char ansprechen,

unsigned char und char , nicht aber signed char .

Wurde das geändert? Bin mir ziemlich sicher dass die Spezialregel in C++03 für alle 3 galt.

EDIT: OK, hab grad selbst nachgesehen... waren immer nur char und unsigned char . Krass. Muss ich mit der "was gilt als String" Regel bei ostream << T* verwechselt haben.

Ich war ja unerwartet viel los. Hätte nicht gedacht, dass ich mit der knappen Frage soviel Wind erzeuge...
Hat zwar bislang keine Probleme bereitet, aber jetzt bin ich doch etwas verunsichert. Also doch sicherheitshalber den Dtor in extra Funktion auslagern und separat aufrufen...

Ich hatte zwar zwischendurch eine Idee, warum es (zuminest in meinem Fall) gehen sollte. Die ist mir aber schon wieder abhanden gekommen...

Eine Frage vielleicht noch:
Speicher reservieren/freigeben hat doch keine Auswirkungen auf den momentanen Inhalt der Speicherstelle, oder??
Wenn ich also direkt nach der Freigabe darauf zugreife, sollte doch der alte Inhalt noch nicht überschrieben sein?!
Wer genau kümmert sich eigentlich um die Speicherverwaltung: Der Compiler oder das OS?!
Wenns der Compiler wäre, würde ich nicht verstehen, warum es als kostspielig angesehen wird.
Aber wenns das OS ist, muss ja für jeden Speicherbereich den ich mir reserviere wieder im Speicher darüber buchgeführt werden... Also "jedes int frisst 2*sizeof(int) Speicher"??

Sind wohl Grundlagen rund um den Computer.. Aber die fehlen halt, wenn man Programmieren nur über diverse Tutorials ausm Netz lernt..

Columbo

Speicher reservieren/freigeben hat doch keine Auswirkungen auf den momentanen Inhalt der Speicherstelle, oder??

Das ist irrelevant. Sie existiert danach für dich nicht mehr.

Also "jedes int frisst 2*sizeof(int) Speicher"??

Ja, vielleicht; aber du wirst ja nicht einen einzelnen int allozieren. Und 8 byte sind recht wenig im Vergleich zu e.g. einer Million.

hustbaer

Spaghettimann schrieb:

Wer genau kümmert sich eigentlich um die Speicherverwaltung: Der Compiler oder das OS?!

Kommt auf die Implementierung an. Wieso sollte das aber nen Unterschied machen? Auch das OS kann Dinge im Usermode machen. Ob der Code in einer Library steht die vom OS oder vom Compiler bereitgestellt wird, macht letztlich keinen Unterschied.

Wobei: primär ist natürlich der Compiler bzw. "die Implementierung" zuständig. Nur gibt es eben Implementierungen die in malloc bzw. ::operator new einfach nur sofort an eine OS Funktion weitergeben.

Spaghettimann schrieb:

Wenns der Compiler wäre, würde ich nicht verstehen, warum es als kostspielig angesehen wird.
Aber wenns das OS ist, muss ja für jeden Speicherbereich den ich mir reserviere wieder im Speicher darüber buchgeführt werden... Also "jedes int frisst 2*sizeof(int) Speicher"??

Njjjjjjaaa-nein

Also gut, ja. In gewissen Fällen könnte der Compiler sagen "hier wird genau ein T zerstört, T ist 123 Byte gross, also geb' ich jetzt mal 123 Byte frei".

Aber: es gibt auch Heap-Implementierungen die siche die Grösse zu jeder Allokation selbst "merken", die viele Allokationen (speziell solche mit Grösse = 1, 2, 4, 8 Byte und etliche andere übliche Grössen) ganz ohne Overhead machen können. Weil sie anhand der Adresse des Speichers auf die Grösse des Blocks rückschliessen können.
Ich glaube sogar dass die meisten mainstream OS' mittlerweile mit solchen Heap-Implementierungen ausgeliefert werden.

@ Arcoth: Stimmt schon, dass das in der Regel nicht viel ausmacht. Andererseits wäre das schlechtestenfalls ein Faktor 2, was die Speicherbelegung angeht..
War mir so einfach nicht wirklich bewusst.

Aber da gibts ja das von hustbaer genannte Konzept, was einfach und genial ist.

Also jedenfalls Danke für den Exkurs. Ist zwar oft garnicht relevant, aber trotzdem gut zu wissen, was da unter der Haube tatsächlich vor sich geht.