Ich lese aktuell das C++ Buch von Breymann und habe eine Frage zum Thema Klassen/Zeiger.

Mal angenommen ich habe ein benutzerdefiniertes Objekt, das weitere Benutzerdefinierte Objekte in sich hat.

bsw

class OBJ
{
private:

 EINOBJ_TYPE1      X;
 EINOBJ_TYPE2      Y;

public:
konstruktoren/funktionen/...
}

EINOBJ_TYPE1 und EINOBJ_TYPE2 sind weiter Klassen, die definiert sind
(mit konstruktor/Funktionen ....)

nun zu meiner frage.

Sollte man die Elementarobjekte X/Y vom Typ EINOBJ_TYP1 /_TYP2 als normale variablen (Objekte) definieren oder als Zeiger in der klasse? was ist besser?

EINOBJ_TYPE1      *X;
 EINOBJ_TYPE2      *Y;

Zu beachten ist, das die klasse OBJ selbst als Zeiger initialisiert wird

int main()
{

OBJ         *pObj;

pObj->DoSth();
pObj->X = ....;
pObj->Y = ....;

]

was ist besser?

Was ist besser, ein LKW oder ein PKW?

Brauchst du einen Verweis auf ein Objekt nimmst du einen Zeiger - brauchst du ein (eigenes) Objekt, dann eben keinen Zeiger. Keines davon ist 'besser'.

Das sind verschiedene Anwendungsfälle. Such mal bei google Aggregation und Komposition. Es geht eigentlich darum. Sollen die Datenelemente sterben wenn das Objekt stirbt, oder sollen sie nicht sterben, weil sie unabhängig vom Objekt sind. Z.B. enthält eine Schule Schüler. Wenn die Schule zu macht, leben die Schüler ja trotzdem weiter, also sind die beiden unabhängig von einander. Anders ist es z.B. bei Haus und Stockerke. Wenn das Haus zusammenbricht, sind auch die Stockwerke kaputt, beide können also nicht ohne einander existieren.

Klingt fragwürdig. Anhand von UML sollte kein Mensch mehr programmieren lernen müssen.

Zu beachten ist, das die klasse OBJ selbst als Zeiger initialisiert wird

int main()
{

OBJ         *pObj;

pObj->DoSth();
pObj->X = ....;
pObj->Y = ....;

]

Hier wird nichts initialisiert und das Programm wird daher vermutlich abstürzen. Dir ist hoffentlich klar, was fehlt.

out schrieb:

Das sind verschiedene Anwendungsfälle. Such mal bei google Aggregation und Komposition. Es geht eigentlich darum. Sollen die Datenelemente sterben wenn das Objekt stirbt, oder sollen sie nicht sterben, weil sie unabhängig vom Objekt sind. Z.B. enthält eine Schule Schüler. Wenn die Schule zu macht, leben die Schüler ja trotzdem weiter, also sind die beiden unabhängig von einander. Anders ist es z.B. bei Haus und Stockerke. Wenn das Haus zusammenbricht, sind auch die Stockwerke kaputt, beide können also nicht ohne einander existieren.

Klingt fragwürdig. Anhand von UML sollte kein Mensch mehr programmieren lernen müssen.

Kannst du das erläutern, wieso das fragwürdig ist, ein Gegenargument oder so. :p

Kannst du das erläutern, wieso das fragwürdig ist, ein Gegenargument oder so. :p

UML-Pläne kann man nie glatt in irgend eine Programmiersprache übersetzen. Haste das noch nicht bemerkt?

Zitat aus Wikipedia http://de.wikipedia.org/wiki/Assoziation_(UML)

Ein Objekt, das Teil eines Ganzen ist, kann zur Lebenszeit zu einem anderen Ganzen wechseln oder sogar ganz in die Unabhängigkeit entlassen werden. Im Gebäude-Beispiel wäre das ein Containergebäude. Wird ein Containergebäude abgebaut, werden die Wohncontainer unabhängig von anderen Objekten. Sie können dann auch allein existieren. Erst wenn man sie zu einem Containergebäude zusammenbaut, werden sie wieder existenzabhängig.

Aha. Sehr spaßig.

out schrieb:

Es geht eigentlich darum. Sollen die Datenelemente sterben wenn das Objekt stirbt

Ähm, wenn mein PC kaputtgeht, lebt die Platte weiter, also verzeigern?

Sebastian Müller schrieb:

Sollte man die Elementarobjekte X/Y vom Typ EINOBJ_TYP1 /_TYP2 als normale variablen (Objekte) definieren oder als Zeiger in der klasse? was ist besser?

Normale Variablen natürlich. Wenn Du irgendwann dann doch mal Zeiger (oder Referenzen) brauchst, merkste das schon.

OBJ *pObj = new OBJ;

***********************************************
Also exestiren die Objekte einer klasse noch, wenn die klasse zerstört wird, wenn ich Zeiger benutze. Jedoch wäre es dann doch praktisch, die Objekte ohne Zeiger zu erzeugen. Weil so ja nur der Zeiger mit dem Objekt "Stirbt". Das Objekt ansich existiert ja immer noch. (nur ohne zeiger darauf). Das Resultat.

Ich zitiere aus meinem Buch
"Speicher leak"

Danke für eure ratschläge

Normale Variablen natürlich. Wenn Du irgendwann dann doch mal Zeiger (oder Referenzen) brauchst, merkste das schon.

Besser kann man es nicht auf den Punkt bringen xD.

Égal ob man nun Pointer braucht oder nicht, es ist 2014, da verwendet man keine Raw-Pointer mehr.

Das mag für besitzende Pointer richtig sein, so generell wie du es sagst aber sicher nicht.

Égal ob man nun Pointer braucht oder nicht, es ist 2014, da verwendet man keine Raw-Pointer mehr. Wenn dann bitte std::unique_ptr<> oder wenn es unbedingt sein muss std::shared_ptr<>. Wenn das Buch das du liest noch normale Pointer lehrt, lege es bitte in die Ecke und kaufe ein richtiges Buch über C++11.

Nö, auch mit C++11 oder C++14 darf man ruhig noch rohe Zeiger benutzen, solange es keine besitzenden Zeiger sind.

Stichwort "Strong Ownership". Korrekt angewendetes "Strong Ownership" (inclusive RAII) macht Pointer zu weiten Teilen komplett überflüssig. Benötigt man dennoch Pointer (weil ein Objekt nicht zur Initialisierungszeit seines besitzenden Objekts initialisiert werden kann) ist ein Smart-Pointer immer die erste Wahl. (Früher scoped_ptr, heute unique_ptr)

Jedes new benötigt ein delete. Selbst das einfachste Programm welches Raw-Pointer verwendet kann nicht ohne großen Aufwand zu betreiben exception-safe programmiert werden. Smart-Pointer sind automatisch exception safe. Kombiniert mit RAII sind memory-leaks ein Ding der Vergangenheit. Siehe hierzu http://www.bromeon.ch/articles/raii.html

Ich kann mir nur noch einen legitimen Gebrauch von Raw-Pointern vorstellen, die Implementierung eines eigenen Smart-Pointer Container.
Hier bin ich aber gerne offen für (legitime) weitere Beispiele

Natürlich kann man heute auch Raw-Pointer verwenden, aber ist es sinnvoll?

Ja. Und zwar wenn man kein Objekt besitzt, sondern nur auf eines verweist (und dieser Verweis auch noch geändert werden kann, was mit Referenzen nicht funktioniert). Eine Ausnahme ist nur dann gegeben wenn man wirklich keine Aussage zur Lebenszeit machen kann (in dem Fall sind shared_ptr ausnahmsweise sinnvoll).

Und dies gilt auch unter C++11 wie wohl auch noch in alle C++-Ewigkeit.

Sowas z.B. (obwohl es ein dämliches Beispiel ist)

auto foo = std::make_unique<Foo>();
// ...
Foo * pF = foo.get();
// ...
foo->stuff();
pF->stuff();
// ...
// delete *foo implizit druch unique_ptr

pF ist zwar ein roher Zeiger, hat aber keinerlei Besitzverantwortlichkeiten. Und wer dann sowas wie delete pF schreibt ist selbst schuld.

Edit: Anwendungsbeispiele sind z.B. klassenhierarchien, wo die oberste Klasse eben den Unique_ptr hält (oder sogar ein "normales" Objekt) und die Kindklassen eben einen Verweis darauf brauchen:

#include <iostream>
#include <vector>
#include <memory>
#include <iterator>
#include <algorithm>

class Foo
{
public:
	void foo() const
	{
		std::cout << "Hallo" << "\n";
	}
};

class Child
{
	Foo * m_foo;

public:
	explicit Child(Foo * pf)
	 : m_foo(pf)
	{}

	void bar() const
	{
		std::cout << this << ".- ";
		this->m_foo->foo();
	}
};

class Parent
{
	std::unique_ptr<Foo> m_foo;
	std::vector<Child> m_children;

public:
	explicit Parent(std::size_t n)
	 : m_foo(new Foo())//(std::make_unique<Foo>())
	{
		std::generate_n(std::back_inserter(this->m_children), n, [&](){return Child{m_foo.get()};});
	}

	void print() const
	{
		std::cout << this << ".-> ";
		this->m_foo->foo();
		for(auto const& c : this->m_children)
		{
			c.bar();
		}
	}
};

int main()
{
	Parent p{5};

	p.print();

	return 0;
}

Und da die Kinder automatisch durch parent gelöscht werden, müssen die sich auch nicht um den Speicher von Foo kümmern. Die Verantwortlichkeit hat auch parent

Das zweite Beispiel erscheint logisch, ich habe aber in meinen bisherigen Projekten eine solche Klassen-Architektur nicht gesehen. Nochmal Stichwort "Strong Ownership". Man findet in jeder Klassen-Architektur immer einen Besitzer für ein Objekt. Müssen andere darauf zugreifen, wenn dann mittels Referenzen.

In der Theorie lass ich mir das ja eingehen, aber in der Praxis habe ich seit der Existenz von smart pointern (genauer shared/unique) keinen Gebrauch mehr von Raw-Pointern machen müssen.

Das erste Beispiel ist wohl nur konstruiert um ein Gegenbeispiel zu bringen oder?

Nein, und das hat auch nichts mit "Strong Ownership" zu tun. Letzteres ist sinnvoll hat aber nichts mit Verweisen zu tun, wo Referenzen nun einmal nicht immer möglich sind (Referenzen können sich nicht ändern und müssen zwangsweise im Konstruktor gesetzt sein).

SeriousITGuy schrieb:

In der Theorie lass ich mir das ja eingehen, aber in der Praxis habe ich seit der Existenz von smart pointern (genauer shared/unique) keinen Gebrauch mehr von Raw-Pointern machen müssen.

Schön für dich, aber ich selbst bin ein Verfechter von Smartpointern, kann dir aus der Praxis aber sagen das man recht häufig nicht besitzende Zeiger verwendet, und nicht immer auf Referenzen ausweichen kann.