Probleme bei Rückgabe eines Objectes nach binärer Operatorüberladung

Chmielewski

Besten dank, soweit habs geklappt. Musste nur den = Operator überladen

Nur gibts mit dem dynamisch erzeugten Objekt "mVector vecres" Probleme. Beim verlassen der Schleife, wo dieses erzeugt wurde, wird der Dekonstruktor vom Vektor aufgerufen. Soweit verständlich. Nur dort gibts dann folgende Exception:

Windows has triggered a breakpoint in Übung1.exe.

This may be due to a corruption of the heap, and indicates a bug in Übung1.exe or any of the DLLs it has loaded.

The output window may have more diagnostic information

//Constructor
mVector::mVector(void)
{
	// init the vector
	m_pArray = new char[m_Alloc];
	assert(NULL != m_pArray); // abort if no memory
	m_Len = 0;
	m_Size = m_Alloc;
}

//Destructor
mVector::~mVector(void)
{
	delete[] m_pArray; // kill the vector
}

Kann mir ehrlich gesagt nicht vorstellen wo da ein Fehler sein sollte

Z2

Vermutlich ist deine Implementierung des Zuweisungs-Operators oder des Copy-Konstruktors fehlerhaft. Im Zweifelsfall mal herzeigen.

Im Übrigen ist das hier

assert(NULL != m_pArray); // abort if no memory

vollkommen sinnlos. Die new Anweisung in der Zeile davor kann keinen Null-Zeiger zurückgeben.

Chmielewski

Diese Abfrage hat mein Prof so in seinen Sampels implementiert - müsste schon stimmen was er sagt.

//Copy-Constructor
mVector::mVector (const mVector &mvec)
{
	m_pArray = new char[mvec.m_Size];
	assert (NULL != m_pArray); // abort if no memory
	memset(m_pArray,0,mvec.m_Size);

	for (int i = 0; i < mvec.m_Len; i++){
		m_pArray[i] = mvec[i];}

	m_Len = mvec.m_Len;
	m_Size = mvec.m_Size;
}

mVector mVector::operator= (const mVector &vec)
{
	if (this != &vec)
	{
		delete (m_pArray);
		m_pArray = new char (vec.m_Size);
		assert(NULL != m_pArray); // abort if no memory
		memset(m_pArray,0,vec.m_Size);

		for (int i = 0; i < vec.m_Len; i++){	
			m_pArray[i] = vec[i];}

		m_Len = vec.getLength();
		m_Size = vec.getSize();
	}
	return *this;
}

Kann mir nicht vorstellen, dass da ein Fehler ist. Aber ist möglich...... c++ kann brutal sein

Z2

Das hier:

delete (m_pArray);

geht so nicht. Auf new[] folgt immer ein delete[]. Das der Code nicht Exception-Sicher ist, sei mal nur am Rande erwähnt.

Und die Abfrage auf den Null-Zeiger ist überflüssig. Sag deinem Prof, daß er keine Ahnung hat.

Edit:

Und das geht so auch nicht:

m_pArray = new char (vec.m_Size);

Eckige Klammern bitte!

Chmielewski

thx - jetzt läufts -> scheiß Klammern vertauscht Und beim Lesen siehste des auch net

Wegen Assert werde ich mal im Inet gleich mal gucken

Chmielewski

hmmm......

http://en.wikipedia.org/wiki/Assertion_(computing)

Comparison with error handling
It is worth distinguishing assertions from routine error handling. Assertions should be used to document logically impossible situations — if the "impossible" occurs, then something fundamental is clearly wrong. This is distinct from error handling: most error conditions are possible, although some may be extremely unlikely to occur in practice. Using assertions as a general-purpose error handling mechanism is usually unwise: assertions do not allow for graceful recovery from errors, and an assertion failure will often halt the program's execution abruptly. Assertions also do not display a user-friendly error message.

Consider the following example of using an assertion to handle an error:

int *ptr = malloc(sizeof(int) * 10);
assert(ptr != NULL);
// use ptr
Here, the programmer is aware that malloc may return a NULL pointer if memory could not be allocated. This is possible: the operating system does not guarantee that every call to malloc will succeed, and the program should be prepared to handle the failure. An assertion is probably not the best choice here, because a malloc failure is not logically impossible — it is a legitimate possibility, albeit not one that will arise very often in practice. The assertion in this example does serve one useful purpose, however: it documents that the programmer has deliberately decided not to provide robust error handling for memory allocation failures.

finix

Google: bad_alloc
Google: std::nothrow

Z2

Oder zum Beispiel das hier:

http://www.cprogramming.com/tips/showTip.php?tip=64&count=30&page=0

Merke: new ist nicht malloc!

Chmielewski

ich sehe es thx. Vielleicht ists bei C so, dass new 0 zurückliefert falls kein Speicher allokiert werden konnte

Z2

In C gibt es kein new. Da gibt es wie gesagt malloc und das kann in der Tat 0 zurückgeben.

lolz

Chmielewski schrieb:

ich sehe es thx. Vielleicht ists bei C so, dass new 0 zurückliefert falls kein Speicher allokiert werden konnte

Dein Professor hat früher mal VS6 benutzt und von dem auf C++ geschlossen, ein sehr beliebter Irrtum.

Ein Tipp: Kauf dir das Buch "OOP für Dummies" damit du die Grundregeln für C++ kennen lernst.
Ein op= implementiert man normalerweise mit dem Kopierkonstruktor.