ich arbeite gerade an einem klassenset für lineares Algebra.
In einer Methode der Matrix klasse erstelle ich eine kopie des aktuellen
Exemplars (Copy konstruktor ist explizit implementiert und funktioniert in anderen Tests). Gegen ende der methode möchte ich das kopierte Exemplar mit delete löschen dabei stürzt das Programm ab.

[cpp]/*Crashing method*/
Matrix* Matrix::myMethod() throw(exception)
{
      /*Make a copy of this Matrix for use as a scratchpad*/
      Matrix thisObjectClone = *this;
      Matrix* Obj = &thisObjectClone;	

      /* further code ..... */

     delete Obj; //free the memory of the scrathpad,[b] program crash![/b]

     return SomeMatrixPtr;
}

/*Copy Constructor of Matrix*/
Matrix::Matrix(const Matrix& M) throw(exception)
	: linearAlgebra(M), nRows(M.nRows), nCols(M.nCols)
{
}

/*Copy Constructor of BaseClass*/
linearAlgebra::linearAlgebra(const linearAlgebra& linAlg) throw(exception)
{
	this->nElements = linAlg.nElements; //copy number of elements
	this->Elements = new ftype[this->nElements]; //reserve memory for Elements

	memcpy ( this->Elements, linAlg.Elements, sizeof(ftype) *   this->nElements); //copy Elements
}
[/cpp]

Im disassembly sehe ich an der Programstelle (x86 ASM) mit dem delete aufruf:

0xb0328be8 <__prelocked_free+280>: movswl 0x14(%eax),%esi
...

verwendete IDE: QNX Momentics Integrated Development Environment Eclipse Version: 4.5.0

Liegt der Fehler an memcpy? Was soll ich sonst verwenden (außer ner Schleife)?

Matrix thisObjectClone = *this;

Dann willst du dieses explizit freigeben, was natürlich zu einem Fehler führt:

delete Obj; // Obj zeigt auf thisObjectClone

Wenn du also eine Klonfunktion willst, solltest du das neue Objekt mit new anlegen, damit es die Funktion überlebt. So brauchst du aber auch eine entsprechende Freigabefunktion. Auch eine Möglichkeit wäre, einen std::auto_ptr zurückzugeben. Wenn die Kopie nur innerhalb der Funktion benötigt wird, lässt du sie auf dem Stack, dann wird sie automatisch abgeräumt.

in diesem fall brauch ich das Exemplar nur innerhalb der methode um temporär damit zu arbeiten.
Das Problem ist eher das das objekt ein dynamisches array enthält das am heap liegt, darum wollt ich es mit delete löschen damit der destruktoraufgerufen wird.

Es ist mir auch nicht möglich nur das array freizugeben:

[cpp]
delete[] Obj->Elements;[/cpp]

da das programm da ebenfalls crasht.

Matrix::~Matrix ()
{
   delete[] Elements;
}

Das Problem ist eher das das objekt ein dynamisches array enthält das am heap liegt, darum wollt ich es mit delete löschen damit der destruktoraufgerufen wird.

Das sollte dich aber nicht kümmern. Wieso hast du das Objekt nicht so eingerichtet, dass es in seinem Destruktor den angeforderten Speicher wieder freigibt? Von aussen Membervariablen freizugeben ist meist schlechtes Design und im Übrigen auch sehr fehler- und leakanfällig.

Wenn die Klasse ihre eigene Speicherverwaltung hat, kannst du schön auf dem Stack arbeiten, und alles wird sauber aufgeräumt.

[code]linearAlgebra::~linearAlgebra() //base class destruktor
{
	delete[] this->Elements;
}[/code]

also ohne:

delete Obj;

wird

~linearAlgebra();

nie ausgeführt.

Oder doch?, wenn ja wann?

Wenn die Klasse ihre eigene Speicherverwaltung hat, kannst du schön auf dem Stack arbeiten, und alles wird sauber aufgeräumt.

Bedeutet "eigene Speicherverwaltung" das im constructor der speicher reserviert wird und im destruktor freigegeben? Das ist so bei mir.
Aber ich dachte der destructor wird nur ausgerufen wenn ich das objekt mit delete entferne.

Wann wird der destructor nun tatsächlich aufgerufen?

Soweit ich es verstehe muss das exemplar mit delete gelöscht werden damit der dekonstruktor aufgerufen wird.

Nicht, wenn das Objekt im automatischen Speicher angelegt worden ist. Dann passiert das .... *trommelwirbel* .... automatisch.

Das ist ja gerade der Witz an den Konstruktoren und Destruktoren. Du kannst "Resourcen" (inklusige reservierten Speicher) in Klassen-Objekte kapseln und die Verwaltung einzig allein dieser Klasse überlassen. Du hättest Dir zB mit einem std::vector viel Ärger ersparen können. Ein vector verwaltet seine Elemente selbst und wenn Du für Deine Matrix-Klasse einen vector statt einem Zeiger als Objekt-Element benutzt hättest, bräuchtest Du auch keinen besonderen Kopier-Konstruktor, Zuweisungsoperator, etc etc etc.

Und sonst: Zu jedem new gehört das entsprechende delete dazu. Das gleiche gilt natürlich auch für new[] und delete[] .

Du solltest diese C++ Basics nachholen. Wie hast Du bisher C++ gelernt?

Gruß,
SP

MrWhite schrieb:

Soweit ich es verstehe muss das exemplar mit delete gelöscht werden damit der dekonstruktor aufgerufen wird.

Nicht, wenn das Objekt im automatischen Speicher angelegt worden ist. Dann passiert das .... *trommelwirbel* .... automatisch.

Hmm, automatischer speicher, kommt in meinem C++ Buch net vor.

Du hättest Dir zB mit einem std::vector viel Ärger ersparen können. Ein vector verwaltet seine Elemente selbst und wenn Du für Deine Matrix-Klasse einen vector statt einem Zeiger als Objekt-Element benutzt hättest, bräuchtest Du auch keinen besonderen Kopier-Konstruktor, Zuweisungsoperator, etc etc etc.

Ich weiß, aber dann wär zu jedem 32bit ftype noch ein 32 ptr gekommen.
Was ich vermeiden wollte.

Und sonst: Zu jedem new gehört das entsprechende delete dazu. Das gleiche gilt natürlich auch für new[] und delete[] .

Ich dachte ein aufruf über den copy constructor wäre ne andere art zu schreiben new... und dann alle elemente mit der hand zu kopieren.

Du solltest diese C++ Basics nachholen. Wie hast Du bisher C++ gelernt?

Gleich wie jeder andere, ich hab dumme fragen in foren gestellt um angepöbelt zu werden wo ich C++ gelernt hab.

mfg MrWhite

Gleich wie jeder andere, ich hab dumme fragen in foren gestellt um angepöbelt zu werden wo ich C++ gelernt hab.

Sei nicht gleich eingeschnappt. Die Frage war berechtigt.

Wenn ich so etwas lese:

Ich dachte ein aufruf über den copy constructor wäre ne andere art zu schreiben new... und dann alle elemente mit der hand zu kopieren.

Dann weist das mich auch darauf hin, dass die Grundlagen einfach nicht verstanden worden sind und würde demjenigen auch raten ein gutes Buch zu kaufen und das sorgfältig durchzuarbeiten.

Hmm, automatischer speicher, kommt in meinem C++ Buch net vor.

Dann ist das Entweder ein schlechtes Buch, Du kannst nicht lesen, oder es wird ein anderer Begriff dafür verwendet. Im Original wird da von "automatic storage" gesprochen.

MrWhite schrieb:

Du hättest Dir zB mit einem std::vector viel Ärger ersparen können. [...]

Ich weiß, aber dann wär zu jedem 32bit ftype noch ein 32 ptr gekommen.
Was ich vermeiden wollte.

Wie bitte? Bist Du sicher?

MrWhite schrieb:

Und sonst: Zu jedem new gehört das entsprechende delete dazu. [...]

Ich dachte ein aufruf über den copy constructor wäre ne andere art zu schreiben new... und dann alle elemente mit der hand zu kopieren.

Falsch gedacht. Nachlesen.

MrWhite schrieb:

Wie hast Du bisher C++ gelernt?

Gleich wie jeder andere, ich hab dumme fragen in foren gestellt um angepöbelt zu werden wo ich C++ gelernt hab.

Dann hast Du ja alles richtig gemacht.

Im Ernst: Ich wollt nur wissen, ob Du ein schlaues Buch verwendest. Da sollte so etwas nämlich drinstehen.

Wenn ich raten sollte:
Du hast einfach Teile des Buchs übersprungen, weil Du gedacht hast, man könne diese Lücken mit dem Wissen über eine andere Programmiersprache füllen. ZB ist Deine Annahme, dass ein std::vector für jedes Element einen Zeiger speichert, einfach falsch. Wir sind hier nicht im Java-Land -- oder was auch immer Dein Background ist. Ok, es ist kein Weltuntergang. Es ist aber Beweis genug, dass Du die Sprachunterschiede unterschätzt hast. -- Nicht persönlich nehmen.

Gruß,
SP

Bzw woher weiß man wo das nächste element ist, wenn seine position weder einem algorithmus folgt noch eine referenz dafür da ist unter welcher adresse man es finden kann. Vorallem wie wird das in Assemble geschrieben, ohne indirekte adressierung oder vorhersagbahre speicherorte?

Buch ist "DirectX9 und Visual C++", hab mir danach nie die mühe gemacht ein weiteres werk über C++ zu lesen, JAVA hab ich tatsöchlich ein buch gelesen, aber ich mag die sprache persönlich net.

Das meißte kann ich umsetzten, wenn dennoch probleme auftreten lese ich konkret nach (habe unter mehreren referenzen copy constructor nachgeschlagen, nirgends stand was von ner anderen speicherverwaltung), wenn das nicht hilft frag ich in nem forum.
Prinzipiell habe ich die Gabe jede frage so zu formulieren das die diskussion eskaliert.

http://www.cplusplus.com/reference/

Dennoch würde ich dir ein Buch, wie z.B "Die C++ Programmiersprache" empfehlen, wo wichtige Sachen, wie die Speichermanagement drin stehen und viele nützliche Details ebenfalls zu finden sind.

Wo kann ich das mit dem STL-vectoren nachlesen? (online)

Zum Beispiel im Forum-Artikel.

MrWhite schrieb:

Bzw woher weiß man wo das nächste element ist, wenn seine position weder einem algorithmus folgt noch eine referenz dafür da ist unter welcher adresse man es finden kann. Vorallem wie wird das in Assemble geschrieben, ohne indirekte adressierung oder vorhersagbahre speicherorte?

Was meinst du mit nächstem Element? Ich verstehe nicht ganz, was du sagen willst.

MrWhite schrieb:

Prinzipiell habe ich die Gabe jede frage so zu formulieren das die diskussion eskaliert.

Wenn du konstruktive Kritik und Verbesserungsvorschläge als Eskalation betrachtest, bist du wahrscheinlich ein wenig empfindlich. In diesem Thread wurde dir wirklich nur geholfen. Ein Hinweis, dass du die Grundlagen nochmals anschauen solltest, liegt wohl noch drin.

Und ich dachte halt an stl::list.

ok, ich hab halt selbst vektoren implementiert,

Es hat meistens keinen Sinn, das Rad neu zu erfinden. Das wird mit grosser Wahrscheinlichkeit fehleranfälliger und ineffizienter als die Standard-Lösung.

MrWhite schrieb:

meine daten werden zur laufzeit net größer, es is alles vorhersagbar, eigentlich
hätt ich alles komplett statisch machen können (wenns net manchmal unbequemer wär).

Dann kannst du dir vielleicht auch mal std::tr1::array (bzw. boost::array ) anschauen. Aber versuch, so wenig wie möglich mit rohen Zeigern und Arrays zu arbeiten.

MrWhite schrieb:

Ja ich muss mich halt selber um den speicher kümmern, aber das eh nur an wenigen stellen in der klasse, das is in dem fall verkraftbar.

Denk dran, Kopierkonstruktor und Zuweisungsoperator auch zu implementieren, sobald du einen selbstgeschriebenen Destruktor hast (Rule of the Big Three).

MrWhite schrieb:

Und ich dachte halt an stl::list.

std::list ist genauso dynamisch wie std::vector . Es handelt sich halt um eine andere Datenstruktur, deren Stärken und Schwächen an anderen Orten liegen.