whole_number_type::whole_number_type(const whole_number_type &b)
       {
         //cout<<endl<<"copy constructor:"<<endl;
         this->count=b.count;//cout<<count<<endl;                                  
         delete[] pBinary_array;
         delete[] pBinary_rest;
         this->pBinary_array=new bool[count];//cout<<endl;
         this->pBinary_rest=new bool[rest_count];
         for(long int i=0;i<this->count;i++){this->pBinary_array[i]=0;}; 
         for(long int i=0;i<this->count;i++){this->pBinary_array[i]=b.pBinary_array[i];}
         //for(long int i=0;i<this->count;i++){ cout<<b.pBinary_array[i];}
         this->sign_of_binary_array=b.sign_of_binary_array; //cout<<endl;      
       };

läuft super und ohne probleme;

Nun bastele ich an einem neuen Prog, und benötige wieder mal eine klasse dessen copy constructor wie folgt aussieht:

twoDimArr( const twoDimArr& p){
		 Rows=p.Rows;
		 Cols=p.Cols;
		 cutoff=p.cutoff;
		 use_cutoff=p.use_cutoff;
		 delete[] pArr;
		 pArr= new float[Rows*Cols];
		 for(int i=0;i<((Rows)* (Cols));i++){pArr[i]=p.pArr[i];};
        };

ob mit this zeiger oder ohne funktioniert das teil tadellos wenn ich z.b.

twoDimArr a(1,2);
twoDimArr c(a);

aufrufe.
Bediene ich mich aber eines this zeigers innerhalb einer methode

twoDimArr b(*this);

beendet windoof das Programm mit einer fehlermeldung.

Ein paar eingefügter cout's später habe ich gesehen dass es beim

delete[] pArr

geschieht.
Interessanterweise verfahre ich in der erstgenannten Klasse genauso, es entstehen aber keine Fehlermeldungen.

Kann mir jemand sagen wo der hase im pfeffer seine Möhren sucht??

gruß und dank

whole_number_type::whole_number_type(const whole_number_type &b)
       {
         //...
         //wurde nie initialisiert und zeigt auch nicht auf NULL
         delete[] pBinary_array;
         //wurde nie initialisiert und zeigt auch nicht auf NULL
         delete[] pBinary_rest;
         //...
       };

In den Pointervaraiablen steht irgendwas drin, also irgendeine Adresse. Und darauf machst Du Dein delete.

ob mit this zeiger oder ohne funktioniert das teil tadellos wenn ich z.b.

twoDimArr a(1,2);
twoDimArr c(a);

aufrufe.
Bediene ich mich aber eines this zeigers innerhalb einer methode

twoDimArr b(*this);

beendet windoof das Programm mit einer fehlermeldung.

Das wiederspricht sich aber ein wenig. Bitte zeig doch mal den genauen Sachverhalt,wo das Programm abstürtzt.

twoDimArr operator+(const twoDimArr& b)
        {
		 twoDimArr c(b);  //hier funzt es
	 	 twoDimArr a(*this); //hier stürzt es bei delete ab
	     for(int r=0;r<(a.Rows * a.Cols);r++)
		 {a.pArr[r]=c.pArr[r]+a.pArr[r];};
	     return a;		  
	    };

gruß und dank

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.

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,..

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.

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).

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

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.

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...

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ß

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?

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];
}

/* 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.

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

Seid gegrüüßt und habt dank.

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