In welchem Speicherbereich wird eigentlich das Objekt "a" angelegt?
Man könnte das Objekt ja auch im Heap speichern, wäre das besser?
Also z.B.

Spieler *a=new Spieler;
...
delete a; //Speicherbereich wieder freigeben
a=0; //Zeiger auf Null setzen

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

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.

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.

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

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

314159265358979 schrieb:

2. 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 schrieb:

314159265358979 schrieb:

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

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.

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

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.

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.