[gelöst] Heap verliert scheinbar grundlos seinen Inhalt

[TyRoXx]

Little Programmer schrieb:

//Hier besteht der komplette Heap nun plötzlich nur noch aus Nullen
	for(int i = 0; i < 64; i++)
	{
		if(FirstByte[i] != 0)
			int a = 1/0;
	}

Findet jemand meinen Fehler?

1. Du hast nicht std::vector<unsigned char> benutzt.
2. Woran erkennst du, dass das nur aus Nullen besteht? Glaubst du etwa, dass ein Compiler für eine Division durch Null sinnvollen Code generiert? Das ist undefiniertes Verhalten, wir sind hier doch nicht in Java! Was du suchst ist assert , ein Debugger oder wenigstens cout .

[SeppJ]

Zeig vollständige Beispiele. Ich wette mal, du hast die Regel der großen drei verletzt. Und ich hoffe mal, das ist nur zur Übung, nicht weil du das produktiv benutzt. Aber selbst dann sind da ein paar fragwürdige Entscheidungen drin, wie die Frage, wieso du dein internes Array dynamisch anforderst, obwohl die Größe doch statisch ist, oder wenn's unbedingt dynamisch sein soll, warum dann nicht vector? In beiden Fällen bräuchtest du dir dann gar keine Sorgen mehr machen. Und das Nullsetzen ist auch ein bisschen umständlich. Und was dein Zuweisungsoperator überhaupt machen soll, ist mir ein Rätsel. Momentan setzt er alles auf Null, was wohl das ist, worüber du dich hier beklagst. Aber was erwartest du denn sonst als Ergebnis, wenn du eine Schleife über alle Werte machst und jedes Mal den Wert 0 zuweist?

[Eisflamme]

Also dein 1/0 soll quasi dumpen, damit Du siehst, dass dort etwas schief läuft? Ich empfehle dafür Exceptions oder assert. Google danach hilft.

Weiters denke ich, Du erstellst eine Instanz der Klasse und füllst diese mit dem Wert 128, was Deine Verwunderung zeigt? Code von main wäre hier hilfreich.

Ansonsten fällt mir auf, dass du delete statt delete[] in deinem dtor nutzt, was natürlich nicht gut bei einem new[] statt new kommt.

[Little Programmer]

Der gcc Compiler warnt zwar, kompiliert aber eine Division durch 0. Sobald diese im Programm aufgerufen wird, führt sie zum Absturz. Ist für mich die schnellste Methode irgendwo im Programm festzustellen was los ist. So wie der Quelltext da steht, produziert er keinen Fehler, deshalb hat das erste Byte meines Heaps an diesen Stellen die abgefragten Werte.

ByteValue ist beim ersten Durchlauf nicht 0 sondern 128, dass hab ich reinkommentiert.

Wenn ihrs ganz komplett haben wollt. Ist aber nur die Wertzuweisung für ByteValue.

Die double, mit welcher das Objekt gleichgesetzt wird, hat bei meinem Test den Wert 0.5

LO512& LO512::operator=(const double& src)
{
	//Veränderbare Kopie der const double machen
	double Value = src;
	unsigned char ByteValue = 0;
	//Alle Bytes durchlaufen
	for(int i = 0; i < 64; i++)
	{
		//Bytewert für neuen Byte reseten
		ByteValue = 0;

		//Zahl mit zwei multiplizieren, wenn über 1, erstes Bit = 1 und Zahl -1 für nächste Rechnung
		Value *= 2;
		if(Value >= 1)
		{
			ByteValue = ByteValue | 128;
			Value -= 1;
			if(Value == 0)
				break;
		}

		//Zahl mit zwei multiplizieren, wenn über 1, zweites Bit = 1 und Zahl -1 für nächste Rechnung
		Value *= 2;
		if(Value >= 1)
		{
			ByteValue = ByteValue | 64;
			Value -= 1;
			if(Value == 0)
				break;
		}

		//Zahl mit zwei multiplizieren, wenn über 1, drittes Bit = 1 und Zahl -1 für nächste Rechnung
		Value *= 2;
		if(Value >= 1)
		{
			ByteValue = ByteValue | 32;
			Value -= 1;
			if(Value == 0)
				break;
		}

		//Zahl mit zwei multiplizieren, wenn über 1, viertes Bit = 1 und Zahl -1 für nächste Rechnung
		Value *= 2;
		if(Value >= 1)
		{
			ByteValue = ByteValue | 16;
			Value -= 1;
			if(Value == 0)
				break;
		}

		//Zahl mit zwei multiplizieren, wenn über 1, fünftes Bit = 1 und Zahl -1 für nächste Rechnung
		Value *= 2;
		if(Value >= 1)
		{
			ByteValue = ByteValue | 8;
			Value -= 1;
			if(Value == 0)
				break;
		}

		//Zahl mit zwei multiplizieren, wenn über 1, sechstes Bit = 1 und Zahl -1 für nächste Rechnung
		Value *= 2;
		if(Value >= 1)
		{
			ByteValue = ByteValue | 4;
			Value -= 1;
			if(Value == 0)
				break;
		}

		//Zahl mit zwei multiplizieren, wenn über 1, siebtes Bit = 1 und Zahl -1 für nächste Rechnung
		Value *= 2;
		if(Value >= 1)
		{
			ByteValue = ByteValue | 2;
			Value -= 1;
			if(Value == 0)
				break;
		}

		//Zahl mit zwei multiplizieren, wenn über 1, achtes Bit = 1 und Zahl -1 für nächste Rechnung
		Value *= 2;
		if(Value >= 1)
		{
			ByteValue = ByteValue | 1;
			Value -= 1;
			if(Value == 0)
				break;
		}

		FirstByte[i] = ByteValue;

		//Hier ist das erste Byte des Heaps 128, es erfolgt kein Fehler
		if(*FirstByte != 128)
			int a = 1/0;
	}

	//Hier tritt auch kein Fehler auf, also sind alle Byte des Heaps 0
	for(int i = 0; i < 64; i++)
	{
		if(FirstByte[i] != 0)
			int a = 1/0;
	}

	return *this;
}

[TyRoXx]

Little Programmer schrieb:

Der gcc Compiler warnt zwar, kompiliert aber eine Division durch 0. Sobald diese im Programm aufgerufen wird, führt sie zum Absturz. Ist für mich die schnellste Methode irgendwo im Programm festzustellen was los ist. So wie der Quelltext da steht, produziert er keinen Fehler, deshalb hat das erste Byte meines Heaps an diesen Stellen die abgefragten Werte.

Das steht wo in der Dokumentation von GCC?
Da steht wohl eher, dass Anweisungen, die undefiniertes Verhalten erzeugen, weggelassen werden können. Die Zuweisung mit der Division wird weggelassen, weil C++ offenlässt, wie solche Fehler behandelt werden. Also behandelt der Compiler den Fehler einfach gar nicht.
Dass das manchmal funktioniert kann sein, aber bei Division durch Null ist kein bestimmtes Verhalten vorgeschrieben. Bei der Optimierung kann die Division wegfallen oder auch nicht.
Einfache Lösung: assert(FirstByte[i] == 0);

[Little Programmer]

Das steht nirgends, das kann man einfach ausprobieren. Hat mich noch nie im Stich gelassen.

Hab den Fehler gerade selbst gefunden. Schon ein wenig peinlich^^. Um Rechenzeit zu sparen hatte ich bei jeder Zuweisung von ByteValue die Abbruchbedingung:

if(Value == 0)
                break;

Damit habe ich, nachdem das erste Byte beschrieben wurde auch die Zuweisung:

FirstByte[i] = ByteValue;

Am Ende der Schleife übersprungen. Meine Testabfrage in der Schleife wurde ebenfalls nie aufgerufen und konnte deshalb keinen Fehler produzieren.
Hab die Abbruchbedingung nun ganz ans Ende der Schleife gesetzt und mein Heap erhält nun auch den Wert.

Danke fürs anschauen an alle und danke @Eisflamme für den Hinweis mit dem delete[]

[TyRoXx]

Little Programmer schrieb:

Danke fürs anschauen an alle und danke @Eisflamme für den Hinweis mit dem delete[]

Nimm einfach std::vector . Der ist das dynamische Array in C++.
Wer mir nur einen Vorteil von new[] nennen kann, bekommt einen Keks.

[Der aus dem Westen ..]

TyRoXx schrieb:

Little Programmer schrieb:

Danke fürs anschauen an alle und danke @Eisflamme für den Hinweis mit dem delete[]

Nimm einfach std::vector . Der ist das dynamische Array in C++.
Wer mir nur einen Vorteil von new[] nennen kann, bekommt einen Keks.

Performance. Wenn du anständig programmierst, ist der direkte Zugriff auf Speicher immer noch schneller als über std:vector . Das ist übrigens der selbe Scheiß wie mit Listen, die will keiner gebrauchen - aber an einer Stelle habe ich durch die Wahl einer Liste das 30-fache an Performance rausgehauen.

Ich will meinen Keks.

[Nexus]

Der aus dem Westen .. schrieb:

Performance. Wenn du anständig programmierst, ist der direkte Zugriff auf Speicher immer noch schneller als über std:vector .

Nur wenn man nicht daran denkt, Laufzeitchecks abzuschalten.

[Der aus dem Westen ..]

Nexus schrieb:

Der aus dem Westen .. schrieb:

Performance. Wenn du anständig programmierst, ist der direkte Zugriff auf Speicher immer noch schneller als über std:vector .

Nur wenn man nicht daran denkt, Laufzeitchecks abzuschalten.

Stimmt schon. Ich wusste früher ja auch nicht, wofür die Projekt- und Linkeroptionen der Compiler gut waren.

Wenn man noch kein wirklicher Profi ist, sollte man schon bei std::vector bleiben, der ist wirklich recht einfach zu verwenden, universell einsetzbar und durch unzählige Produktivtests von Fehlern und Bufferüberläufen befreit. Nur, wenn es darauf ankommt, sollte man wirklich zu new[] greifen - meine Meinung.

[SeppJ]

Der aus dem Westen .. schrieb:

Wenn man noch kein wirklicher Profi ist, sollte man schon bei std::vector bleiben, der ist wirklich recht einfach zu verwenden, universell einsetzbar und durch unzählige Produktivtests von Fehlern und Bufferüberläufen befreit. Nur, wenn es darauf ankommt, sollte man wirklich zu new[] greifen - meine Meinung.

Nochmal: wieso? Das Performanceargument wurde dir schon widerlegt und du kannst das auch gerne nachmessen. Wenn du was anderes rausbekommst als Gleichheit, dann gehörst du zu den nicht-wirklichen Profis und solltest sowieso die Finger von so etwas lassen.

Ein std::vector (mit dem Standardallocator) ist new[] mit dem ganzen RAII-Gemurksel drumrum, welches man sowieso programmieren müsste (und welches auch nichts kostet). Und einem guten Interface 9welches auch nichts kostet). Und mit optionalen Debugfeatures (kosten auch nichts, wenn nicht benutzt). new[] ist daher immer in allen Belangen schlechter als vector.

Dir sollte man für die Antwort schon eher einen Antikeks geben, weil es genau das unreflektierte Wiederholen solcher Legenden ist, die Anfänger zu new[] treibt.

[keksfresser]

Der std::vector speichert ganze drei Pointer ab (begin, end, endofstorage) und unnötigerweise noch einen Allokator.

Und auch wenn man am Anfang reserve() macht und mit höchsten Compileroptimierungen übersetzt; push_back bleibt immer ein ungeinlineter Funktionsaufruf, der ein inkrementieren des end-Pointers mit sich bringt. Der muss von meinem Code auch noch gespeichert werden (ich muss eine for-loop über int machen anstatt T*). Höchst ineffizient. Wenn ich resize() nehme, werden POD-Konstruktoren aufgerufen.

std::vector<> ist unvertretbar schlecht für sehr viele kleine Arrays mit konstanter Grösse und nachteilig für grössere push_back-Geschichten. Dein "kostet nichts" ist übertrieben.

[SeppJ]

keksfresser schrieb:

Der std::vector speichert ganze drei Pointer ab (begin, end, endofstorage) und unnötigerweise noch einen Allokator.

Du willst über Optimierung diskutieren und kennst nicht einmal Empty Base Optimization?

Und auch wenn man am Anfang reserve() macht und mit höchsten Compileroptimierungen übersetzt; push_back bleibt immer ein ungeinlineter Funktionsaufruf, der ein inkrementieren des end-Pointers mit sich bringt.

Wieso ungeinlined? Wieso wäre das bei einem selbstverwalteten Array anders? Da musst du auch wissen, wo das Ende ist.

std::vector<> ist unvertretbar schlecht für sehr viele kleine Arrays mit konstanter Grösse und nachteilig für grössere push_back-Geschichten. Dein "kostet nichts" ist übertrieben.

Warum solte man vector fur Arrays konstanter Größe nehmen? Da würdest du ja auch kein new[] nehmen. Deine Aussagen sind solche Blödsinn, dass ich bei einem Unregisitrierten annehmen muss, dass du nur trollen möchtest.

[TyRoXx]

keksfresser schrieb:

Der std::vector speichert ganze drei Pointer ab (begin, end, endofstorage) und unnötigerweise noch einen Allokator.

Der Allocator kann von einem schlauen Compiler weggelassen werden.
Das doppelte Ende ist eine Optimierung für push_back , der eine Zeiger ist aber verschmerzbar, wenn man ihn nicht braucht. Macht in der Praxis einfach keinen Unterschied ob der nun da ist oder nicht. Das wäre eine Mikrooptimierung, die in der Messungenauigkeit untergeht.

Ich muss aber zugeben, dass vector damit nicht ganz dem C++ Prinzip entspricht, dass man nur das bezahlt, was man auch benutzt. Übersehe ich etwas oder fehlt da wirklich ein Container für ein dynamisches Array garantiert ohne push_back -Optimierung?
Ein Kompromiss ist unique_ptr<T []> : Kein Komfort, aber wenigstens kein Leak.

keksfresser schrieb:

Und auch wenn man am Anfang reserve() macht und mit höchsten Compileroptimierungen übersetzt; push_back bleibt immer ein ungeinlineter Funktionsaufruf, der ein inkrementieren des end-Pointers mit sich bringt. Der muss von meinem Code auch noch gespeichert werden (ich muss eine for-loop über int machen anstatt T*). Höchst ineffizient. Wenn ich resize() nehme, werden POD-Konstruktoren aufgerufen.

Was hat push_back jetzt damit zu tun?
Das mit der Schleife ergibt keinen Sinn.
new[] ruft doch auch den Standardkonstruktor auf? push_back ruft hingegen gar keinen Standardkonstruktor auf.

keksfresser schrieb:

std::vector<> ist unvertretbar schlecht für sehr viele kleine Arrays mit konstanter Grösse und nachteilig für grössere push_back-Geschichten.

Konstante Größe? Joa, da nimmt man array .
Das tolle an vector ist ja gerade, dass er perfekt für " push_back -Geschichten" ist. Du hast einfach nur keine Ahnung.

keksfresser schrieb:

Dein "kostet nichts" ist übertrieben.

Dein "kostet was" ist nicht nur übertrieben, sondern aus der Luft gegriffen.

Falls der Beitrag als Scherz gemeint war, bitte nächstes Mal irgendeinen Hinweis auf Ironie hinterlassen.

[keksfresser]

SeppJ schrieb:

keksfresser schrieb:

Der std::vector speichert ganze drei Pointer ab (begin, end, endofstorage) und unnötigerweise noch einen Allokator.

Du willst über Optimierung diskutieren und kennst nicht einmal Empty Base Optimization?

Gut, lass den Allokator weg. Es bleibt der Overhead von einem Pointer.

Wieso wäre das bei einem selbstverwalteten Array anders? Da musst du auch wissen, wo das Ende ist.

Irgendwie muss ich dem Vektor sagen, wie gross er sein soll. vec.resize(n). Dann speichere ich n *und* das Ende ab; Nochmals overhead von einem Pointer.

Deine Aussagen sind solche Blödsinn, dass ich bei einem Unregisitrierten annehmen muss, dass du nur trollen möchtest.

Deine Sprech ist solche Fehler, dass ich bei einem Modirerator annehmen.

[keksfresser]

TyRoXx schrieb:

Ich muss aber zugeben, dass vector damit nicht ganz dem C++ Prinzip entspricht, dass man nur das bezahlt, was man auch benutzt. Übersehe ich etwas oder fehlt da wirklich ein Container für ein dynamisches Array garantiert ohne push_back -Optimierung?
Ein Kompromiss ist unique_ptr<T []> : Kein Komfort, aber wenigstens kein Leak.

Jupp, Punkt für new.

new[] ruft doch auch den Standardkonstruktor auf?

Nein, tuts nicht. new[] () macht das.

keksfresser schrieb:

Falls der Beitrag als Scherz gemeint war, bitte nächstes Mal irgendeinen Hinweis auf Ironie hinterlassen.

Ne, der Grund war zu tollen.

[314159265358979]

Vielleicht sollte man erst einmal sagen, wann man vector besser nicht (bzw nicht direkt) verwenden sollte. Wenn ich ein Array fester Größe brauche, diese aber erst zur Laufzeit feststeht, ist vector, sagen wir mal, suboptimal, durch die zusätzlichen Verwaltungsdaten. Bei einer Dimension ist das ganze nicht wirklich schlimm, aber spätestens bei 3 Dimensionen fallen die Verwaltungsdaten besonders bei kleinen Arrays ins Gewicht. Auch sind 3 geschachtelte Vektoren nicht gerade Cache-freundlich und somit langsam.

Bei mehr als 1 Dimension würde ich den vector in eine Klasse stecken, die mir die Elemente auf ein 1-dimensionales Array mappt, bzw wenn die Größe zur Laufzeit konstant bleibt, würde ich unique_ptr<T[]> wrappen, um noch ein paar Bytes rauszuholen.

[TyRoXx]

keksfresser schrieb:

new[] ruft doch auch den Standardkonstruktor auf?

Nein, tuts nicht. new[] () macht das.

Mein Compiler tut das und selbst wenn er es nicht täte, wäre das ein Argument gegen new[] . Was will man denn mit einer Folge nicht initialisierter Objekte?

314159265358979 schrieb:

Vielleicht sollte man erst einmal sagen, wann man vector besser nicht (bzw nicht direkt) verwenden sollte. Wenn ich ein Array fester Größe brauche, diese aber erst zur Laufzeit feststeht, ist vector, sagen wir mal, suboptimal, durch die zusätzlichen Verwaltungsdaten.

Hallo? Es geht hier um einen Zeiger pro vector -Instanz. Schreib für deine Bedürfnisse einen Container, der mit zwei Zeigern auskommt, aber vergiss den unique_ptr -Hack.

314159265358979 schrieb:

Bei einer Dimension ist das ganze nicht wirklich schlimm, aber spätestens bei 3 Dimensionen fallen die Verwaltungsdaten besonders bei kleinen Arrays ins Gewicht. Auch sind 3 geschachtelte Vektoren nicht gerade Cache-freundlich und somit langsam.

Niemand, der bei Trost ist, würde das so implementieren.

314159265358979 schrieb:

Bei mehr als 1 Dimension würde ich den vector in eine Klasse stecken, die mir die Elemente auf ein 1-dimensionales Array mappt, bzw wenn die Größe zur Laufzeit konstant bleibt, würde ich unique_ptr<T[]> wrappen, um noch ein paar Bytes rauszuholen.

Spart immer noch einen Zeiger. In anderen Worten: Acht Bytes. Eine enorme Ersparnis bei einer typischerweise tausende Bytes großen Matrix, nicht? Also um Speicher an sich geht es hier nicht.
Der einzige Fall, in dem der kleinere vector messbar schneller sein kann:
Iteration über eine lange Folge von vector en ohne die Elemente der vector en anzufassen. Der unnötige Zeiger braucht Platz im Cache und erfordert damit häufigeres Nachladen.

Wie gesagt: Es gibt noch keine optimale Lösung für das Problem. vector ist der sehr gute Kompromiss, wenn man man ihn nicht mit zwei Zeigern nachbauen möchte oder kann.

[Ethon]

Wieso wird hier über die Performance von std::vector schlecht geredet? Soetwas besitzt ein new[] Array gar nicht. Von daher steht das nicht zur Debatte.
Der einzige Unterschied ist ein zusätzlicher Pointer auf Seiten des Vektors, nämlich ganze 4/8 Byte auf gängen Maschienen. Das ist extrem vernachlässigbar.

[SeppJ]

@TyRoXx: Pi hat schon recht (das ich das mal sagen wurde ). vector wäre da deutlich langsamer und deutlich verschwenderischer als statische Arrays. vector ist kein Kompromiss. vector ist wie new[]. Meistens will man auch dynamische Arrays. Aber wenn man sie nicht braucht, dann nimmt man weder vector noch new.