Heap nutzen ja/nein? -GELÖST-

redrew99

314159265358979 schrieb:

Es würde auch nichts bringen, den Zeiger auf 0 zu setzen, lass das bleiben, ohne einen guten Grund zu haben.

Ok, dachte daß das sinnvoll ist, um zu verhindern, daß z.B. ein erneutes "delete" auf die gleiche Adresse aufgerufen wird.
Kann es ausserdem nicht zu Fehlern im Programm kommen, wenn der Zeiger irgendwohin
zeigt?

cooky451

redrew99 schrieb:

Ok, dachte das sinnvoll ist, um zu verhindern, daß z.B. ein erneutes "delete" auf die gleiche Adresse aufgerufen wird.
Kann es ausserdem nicht zu Fehlern im Programm kommen, wenn der Zeiger irgendwohin
zeigt?

Nein, nicht solange du nicht auf die Idee kommst irgendetwas komisches mit ihm zu machen. Der Zeiger selbst interessiert sich nicht für seinen Wert.

GorbGorb

Generell würde ich wenn möglich den stack verwenden, nur wenn du sehr viel oder dynamisch Speicher brauchst solltest du den heap verwenden.

krümelkacker

redrew99 schrieb:

In welchem Speicherbereich wird eigentlich das Objekt "a" angelegt?

Im automatischen Speicher. Man sagt dazu auch manchmal "Stack" weil der automatische Speicher meistens durch einen Stack implementiert wird.

In C++ gibt es drei Speicherbereiche:
- automatisch
- statisch
- Freispeicher ("Heap")

Wo Du ein Objekt ablegst, hat auch Implikationen bezüglich der Lebenszeit des Objekts. Bitte nochmal im schlauen Buch dazu nachschlagen.

KN4CK3R

ich hab zu dem Thema auch eine Frage:
angenommen ich möchte einen "Baum" aufbauen und habe solche Klassen:

class Node
{
private:
	std::string name;
	...

public:
	static Node CreateNode(const std::string &name)
	{
		Node node;
		node.name = name;
		return node;
	}
};

class Tree
{
private:
	std::list<Node> nodeList;
	...

	void func()
	{
		nodeList.push_back(Node::CreateNode("node"));
		...
	}
}

Belaste ich damit den Heap oder den Stack? CreateNode gibt eine auf dem Stack erzeugte Variable zurück, die in der nodeList gespeichert wird. std::list benutzt aber den Heap(?) zur Verwaltung der Elemente oder? Wird Node dann im großen Heap verwaltet oder bleibt die Variable im kleinen Stack?

greetz KN4CK3R

krümelkacker

list kopiert das Ding für sich. Das, was createNode zurückgibt ist ein temporäres Objekt, was anschließend zerstört wird.

cooky451

Auf dem Heap, aber wie wär's mit nem Konstruktor?

_matze

314159265358979 schrieb:

Es würde auch nichts bringen, den Zeiger auf 0 zu setzen, lass das bleiben, ohne einen guten Grund zu haben.

Quatsch, wieso das denn? Es ist doch sogar sehr oft üblich, Zeiger auf 0 zu prüfen, bevor darauf zugegriffen wird. Da wäre es fatal, wenn noch eine ehemals gültige Adresse drinstehen würde. Sobald es möglich ist, dass eine Zeigervariable nach dem delete noch mal abgefragt wird, sollte man unbedingt 0 zuweisen.

_matze schrieb:

314159265358979 schrieb:

Es würde auch nichts bringen, den Zeiger auf 0 zu setzen, lass das bleiben, ohne einen guten Grund zu haben.

Quatsch, wieso das denn? Es ist doch sogar sehr oft üblich, Zeiger auf 0 zu prüfen, bevor darauf zugegriffen wird. Da wäre es fatal, wenn noch eine ehemals gültige Adresse drinstehen würde. Sobald es möglich ist, dass eine Zeigervariable nach dem delete noch mal abgefragt wird, sollte man unbedingt 0 zuweisen.

Nö, 0 erzeugt pseudo-definiertes Verhalten.
Ein double-delete kracht immer und man kann schnell den Fehler finden.

_matze

Ethon_notloggedin schrieb:

_matze schrieb:

314159265358979 schrieb:

Es würde auch nichts bringen, den Zeiger auf 0 zu setzen, lass das bleiben, ohne einen guten Grund zu haben.

Quatsch, wieso das denn? Es ist doch sogar sehr oft üblich, Zeiger auf 0 zu prüfen, bevor darauf zugegriffen wird. Da wäre es fatal, wenn noch eine ehemals gültige Adresse drinstehen würde. Sobald es möglich ist, dass eine Zeigervariable nach dem delete noch mal abgefragt wird, sollte man unbedingt 0 zuweisen.

Nö, 0 erzeugt pseudo-definiertes Verhalten.
Ein double-delete kracht immer und man kann schnell den Fehler finden.

Und wenn der Zeiger aber wirklich in einer Programmausführung nicht verwendet wurde, einfach weil er nicht gebraucht wurde? Soll's dann krachen, obwohl im Grunde nichts schiefgegangen ist? Nö.

cooky451

_matze schrieb:

Und wenn der Zeiger aber wirklich in einer Programmausführung nicht verwendet wurde, einfach weil er nicht gebraucht wurde? Soll's dann krachen, obwohl im Grunde nichts schiefgegangen ist? Nö.

Wenn er nicht verwendet wurde, kracht es auch nicht.

SeppJ

_matze schrieb:

Und wenn der Zeiger aber wirklich in einer Programmausführung nicht verwendet wurde, einfach weil er nicht gebraucht wurde? Soll's dann krachen, obwohl im Grunde nichts schiefgegangen ist? Nö.

Wenn du Lesend, Schreibend oder Löschend auf einen Zeiger zugreifst den du vorher gelöscht hast, dann ist etwas gründlich schiefgelaufen und es ist angebracht, es ordentlich krachen zu lassen, anstatt den Fehler zu vertuschen.

_matze

cooky451 schrieb:

_matze schrieb:

Und wenn der Zeiger aber wirklich in einer Programmausführung nicht verwendet wurde, einfach weil er nicht gebraucht wurde? Soll's dann krachen, obwohl im Grunde nichts schiefgegangen ist? Nö.

Wenn er nicht verwendet wurde, kracht es auch nicht.

Wieso sollte es? Wenn vor dem eigentlichen Zugriff auf 0 geprüft wird, kracht natürlich gar nix. Die 0 signalisiert doch schließlich (wenn man es so vereinbart hat), dass der betreffende Programmteil, der auf diesen Zeiger aufbaut, momentan nicht eingesetzt wird. Bei uns könnte sowas z.B. bedeuten, dass eine bestimmte Bilderfassungsquelle nicht verfügbar ist. Daher wurde kein passendes Handle erzeugt und dem Zeiger im struct keine Adresse auf ein gültiges Handle verpasst. Das ist dann auch völlig in Ordnung und hat überhaupt nix mit Fehler Vertuschen zu tun. Es ist kein Programmfehler.

Man kann jetzt darüber streiten, ob man sowas designtechnisch auch anders lösen kann. Kann man natürlich. Man könnte sich irgendwelche Schalter basteln, die einem signalisieren, dass man auf Zeiger xy nicht zugreifen darf (bool, bitflags, wasauchimmer). Oder man akzeptiert, dass eine 0 denselben Zweck erfüllen kann.

SeppJ

_matze schrieb:

Wieso sollte es? Wenn vor dem eigentlichen Zugriff auf 0 geprüft wird, kracht natürlich gar nix. Die 0 signalisiert doch schließlich (wenn man es so vereinbart hat), dass der betreffende Programmteil, der auf diesen Zeiger aufbaut, momentan nicht eingesetzt wird. Bei uns könnte sowas z.B. bedeuten, dass eine bestimmte Bilderfassungsquelle nicht verfügbar ist. Daher wurde kein passendes Handle erzeugt und dem Zeiger im struct keine Adresse auf ein gültiges Handle verpasst. Das ist dann auch völlig in Ordnung und hat überhaupt nix mit Fehler Vertuschen zu tun. Es ist kein Programmfehler.

Man kann jetzt darüber streiten, ob man sowas designtechnisch auch anders lösen kann. Kann man natürlich. Man könnte sich irgendwelche Schalter basteln, die einem signalisieren, dass man auf Zeiger xy nicht zugreifen darf (bool, bitflags, wasauchimmer). Oder man akzeptiert, dass eine 0 denselben Zweck erfüllen kann.

Das ist ein völlig anderer Anwendungsfall. Wenn durch die 0 tatsächlich etwas signalisiert wird, dann ist das sogar sehr sinnvoll und das Mittel der Wahl. Aber ein pauschales Nullsetzen wie das woran sich hier die Diskussion entzündet hat, ist meistens Unsinn und wird von Leuten verbreitet, die mal diese sinnvollen Fälle gesehen, aber nicht verstanden haben.

_matze

SeppJ schrieb:

Aber ein pauschales Nullsetzen wie das woran sich hier die Diskussion entzündet hat, ist meistens Unsinn und wird von Leuten verbreitet, die mal diese sinnvollen Fälle gesehen, aber nicht verstanden haben.

Na ja, ich habe mich eigentlich nur gegen das pauschale Nicht-Null-Setzen gewehrt.