merkwürdiges verhalten von delete []

Tachyon

Häh, in dem Thread stehts doch gerade andersrum. Im Konstruktor gibts noch nichts zu löschen. Du produzierst undefiniertes Verhalten.

drakon

Ich muss jetzt doch auf Tachyon verweisen.

Du erzeugst ja mit dem copy-ctor ein neues Objekt, bei welchem du aber noch NIE new auf pArr angewendet hast. Folglich löscht du hier Speicher, der nicht reserviert ist.

zeusosc

Int_t *my_ints = new Int_t[10];

...

delete []my_ints;

This tells the delete operator to go and find the array size, and delete all the objects.

bei zerosize sollte also nüx passieren,..

Tachyon

zeusosc schrieb:

Int_t *my_ints = new Int_t[10];

...

delete []my_ints;

This tells the delete operator to go and find the array size, and delete all the objects.

bei zerosize sollte also nüx passieren,..

Das geht so nicht. Für Dein Array gibts nicht "zerro size" sondern irgendwas. Da wurde nie was definiert. Es steht einfach Schrott in der Zeigervariablen.

drakon

zeusosc schrieb:

Int_t *my_ints = new Int_t[10];

...

delete []my_ints;

This tells the delete operator to go and find the array size, and delete all the objects.

bei zerosize sollte also nüx passieren,..

Dir ist schon klar, dass der "normale" ctor nicht vor dem dopy-ctor aufgerufen wird, oder? in pArr kann so ziemlich alles drin stehen. (Und wenn dort zufälligerweise 0 drin steht, dann kriegst du keine Fehlermeldung).

zeusosc

Ja stimmt, Du hast recht, (ctor wird beim aufruf des copy-ctor's gar nicht aufgerufen soweit ich weiß)

ich flush'e den speicherbereich ainfach auf zero nach der allokation,..
dann dürften auch keine weiteren probleme auftreten,..

Ich danke für eure gedult und hilfe

drakon

zeusosc schrieb:

ich flush'e den speicherbereich ainfach auf zero nach der allokation,..
dann dürften auch keine weiteren probleme auftreten,..

Ich danke für eure gedult und hilfe

Warum den das?! Lass einfach das delete[] da weg. Es heisst ja nicht umsonst copyKONSTRUKTOR, weil du da ja etwas erzeugen(konstruieren) willst und nicht etwas zerstören.

@Tachyon in der Zukunft:
Genau das habe ich auch das Gefühl.

Tachyon

zeusosc schrieb:

Ja stimmt, Du hast recht, (ctor wird beim aufruf des copy-ctor's gar nicht aufgerufen soweit ich weiß)

ich flush'e den speicherbereich ainfach auf zero nach der allokation,..
dann dürften auch keine weiteren probleme auftreten,..

Ich danke für eure gedult und hilfe

Irgendwie habe ich das dumpfe Gefühl, dass Du immer noch auf dem Holzweg bist...

zeusosc

Wieso bin ich aufm holzweg??

Ich habe schon mehrfach erlebt das bei einer durch new erzeugten Array die elemente nicht leer sind. Das wollte ich umgehen. Da delete[] mir ärger macht lasse ich dieses weg, allokiere den speicher und setze deren Inhalt auf null. Was ist an diesem verfahren falsch?

gruß

Tachyon

zeusosc schrieb:

Wieso bin ich aufm holzweg??

Ich habe schon mehrfach erlebt das bei einer durch new erzeugten Array die elemente nicht leer sind. Das wollte ich umgehen. Da delete[] mir ärger macht lasse ich dieses weg, allokiere den speicher und setze deren Inhalt auf null. Was ist an diesem verfahren falsch?

gruß

Was heisst "nicht leer"? Nicht mit 0 initialisiert?

zeusosc

Ja.

LordJaxom

zeusosc schrieb:

Wieso bin ich aufm holzweg??

Siehe unten

Ich habe schon mehrfach erlebt das bei einer durch new erzeugten Array die elemente nicht leer sind.

Elemente eines Arrays können nie leer sein. Sie können höchstens einen Wert von 0 haben, aber das ist genauso ein Wert wie 1, 2, 3.5, ... Frisch allokierte POD-Arrays haben - wenn nicht anders angegeben, dazu unten mehr - keine definierten Vorgabewerte, sondern enthalten "Müll".

BTW, kann auch Dein Zeiger, wenn Du ihn nicht initialisierst (sei es mit 0 oder dem Ergebnis von new T[]) Müll enthalten. Das gibt Dir aber noch lange nicht das Recht, das, worauf der Müll zufällig zeigt, zu löschen.

Das wollte ich umgehen.

Da gibt es eigentlich nichts zu umgehen. Es gibt höchstens die Notwendigkeit, dass das Array nach der Allokation mit bestimmten Werten vorbelegt wird, was man einfach erreichen muss. Auch dazu siehe unten.

Da delete[] mir ärger macht

Kein Wunder, man kann nichts löschen, was man vorher nicht erzeugt hat.

lasse ich dieses weg,

Guuute Entscheidung

allokiere den speicher und setze deren Inhalt auf null. Was ist an diesem verfahren falsch?

Ab hier ist an dem Verfahren nichts mehr falsch.

Und nun noch zu dem Tip: Es gibt in C++ die sogenannte Default-Initialisierung, die bei PODs auf Value-Initialisierung hinausläuft auch bei Arrays. Value-Initialisierung bedeutet, dass mit einer in den Zieltyp konvertierten 0 initialisiert wird.

Das Beispiel zum Tip:

twoDimArr(const twoDimArr& p)
{ 
    /* An diesem Punkt sind ALLE Member uninitialisiert. Sie enthalten Müll. Wenn der Müll nach sinnvollen Daten aussieht, ist das Zufall. */
    ...

    pArr = new float[Rows*Cols] (); // das leere Klammernpaar bewirkt Value-Initialisierung

    /* durch die Value-Initialisierung enthält pArr lauter Nullen */

    /* ist aber eigentlich garnicht nötig, da du hier die Werte sowieso alle direkt überschreibst: */
    for(int i=0; i<((Rows)* (Cols)); i++)
        pArr[i]=p.pArr[i];
}

camper

LordJaxom schrieb:

/* durch die Value-Initialisierung enthält pArr lauter Nullen */

pArr tut das nicht. Für das Array, in das pArr zeigt, trifft die Aussage dagegen zu. Mir ist klar, dass du das weißt, aber es könnte missverstanden werden.

zeusosc

Ich danke euch. Das mit der standartval-init wusste ich net.

Das mit "leer" war auch nur als saloppe metapher gemeint.

Seid gegrüüßt und habt dank.

LordJaxom

camper schrieb:

pArr tut das nicht. Für das Array, in das pArr zeigt, trifft die Aussage dagegen zu. Mir ist klar, dass du das weißt, aber es könnte missverstanden werden.

Du hast natürlich recht, und ich muss dringend an der Präzision meiner Formulierungen arbeiten