Ich habe eine Klasse Parent, welches zwei Methoden besitzt.
Die erste Methode liefert ein Object zurück, welche vom Parent freigegeben wird.

Child *getChild()
{
	return child;
}

Die zweite Methode liefert ein Object zurück, welche vom aufrufer freigegeben werden muss.

Child *getNewChild()
{
	return new Child();
}

Wie muss ich die Methoden deklarieren, das man es sofort erkennt.

mfg
funcky

class Child
{
public:
	Child()
	{
		value = 1;
	}

	~Child();

	int getValue()
	{
		return value;
	}

private:
	int value;

};

class Parent
{
public:
	Parent()
	{
		child = new Child();
	}

	~Parent();

	Child *getChild()
	{
		return child;
	}

	Child *getNewChild()
	{
		return new Child();
	}

private:
	Child *child;

};

int main(int argc, char* argv[])
{
	Parent p;

	Child *c1 = p.getChild();
	Child *c2 = p.getNewChild();

	printf("Hallo Welt!\n");

	return 0;
}

Bau doch einfach eine Klasse um deine Konstruktion herum, die sich um den ganzen Kram kümmert. Falls es ein Baum werden soll, versteh ich den Sinn nicht, warum ein neues "Kind" erzeugt wird, aber nicht gespeichert.

es geht mir nicht darum einen Baum zu erzeugen.
Ich möchte in Parent ein Object erzeugen und diese dem Aufrufer zurück geben.
In der Methode "getChild()" soll ein Object zurück gegeben werden, welche für
die Speicherverwaltung Parent zuständig ist.
In der Methode "getNewChild()" soll ein Object zurück gegeben werden, welche für die Speicherverwaltung der Aufrufer zuständig ist.
Und dies soll der Aufrufer anhang der Deklarion von der Methode erkennen können.
Wenn ich die Methode "getChild()" so deklariere:

const Child *getChild();

kann ich die Methoden von Child nicht mehr aufrufen.

Wie muss ich vor gehen?

Was macht man den mit Mthoden, die ein Objekt erzeugt und zurück geben sollen ?

mfg
funcky

Also solltest du:
- versuchen deine Objecte nicht als zeiger, sondern alls referenzen zu uebergeben. Deine Objecte sollten sich am besten weitgehend aehnlich wie POD's verhalten. Also CCTOR zuweisungsop usw implementieren.

Das geht in vielen faellen natuerlich nicht. Dynamischen Speicher speicher hat man ja nich umsonst eingefuehrt.
rohe zeiger sind in c++ die schlechteste veriante. sollt man nur intern verwenden, also als autor von biblotheken sollte der user (benutzende programmierer) davonb nix zu sehen bekommen. Da sind dan, je nach anwendungsfall, entweder generische wrapper fuer zeiger eine möglichkeit (smartpointer - auto_ptr usw ...) oder spezialisierte wrapper fuer dein ganz bestimmtes object.

Das ist natuerlich auch ne frage des aufwands ... aber grad fuer schnittstellen wo mehr als 1 programmierer beteiligt ist, lohnt sich so nen sauberes design fast immer .

Ciao ...

DU bist bei C++ und nicht bei C ...

Also solltest du:
- versuchen deine Objecte nicht als zeiger, sondern alls referenzen zu uebergeben.

In dem Fall noch schlimmer als rohe Zeiger.

Wenn man nicht will, das der User sich selbst drum kümmern muß die Objekte zu löschen, sollte man Smartpointer benutzen. auto_ptr ist ein Möglichkeit, wobei dieser auch ein sehr spezielles Verhalten hat. Den benutze ich zwar auch gerne, aber er ist nicht immer für den User sinnvoll. Dann doch eher z.B. shared_ptr benutzen (ist im TR1 drin oder halt aus boost, wenn TR1 nicht verfügbar).

"versuchen deine Objecte nicht als zeiger, sondern alls referenzen zu uebergeben."
Bei meinem Fall werden Objecte nicht übergeben, sondern zurück gegeben.

"Deine Objecte sollten sich am besten weitgehend aehnlich wie POD's verhalten. Also CCTOR zuweisungsop usw implementieren."
Was sind POD's und CCTOR ?

Ich werde in Zukunft auto_ptr benutzen oder für meine Klassen ein MemoryManager schreiben, welches sich die dynamisch erzeugten Objecte merkt und am Ende löscht.

mfg
funcky

Bei meinem Fall werden Objecte nicht übergeben, sondern zurück gegeben.

nen rueckgabeparameter iss nix anderes wie nen paramater nur in die andere Richtung ... insofern ist es eine uebergabe der funktion an die ausfuehrende instanz. Und da ist in c++ technisch kein unterschied, es sind die selben regeln.

POD = plain old data : also einfache datentypen + simple strukturen int als typ ist z.b. nen pod
CCTOR = copy constructor

ob Smartpointer sinvoll sind, entscheidet eigentlich der anwendungsfall ...

Die gradwanderung beim c++ programmieren ist halt, mögliche fehlerquellen fruehzeitig zu erkennen und drauf mit geeignetem design zu reagieren, die performance nich ausm auge zu verlieren und dabei noch den aufwand in grenzen halten. Grad als Bibliothekentwickler kommst da nie auf ne 100% loesung, sondern immer nur auf die am meisten tragbarsten Kompromisse.

bei deinem rueckgabedingens problem die optimale loesung zu finden, da fehlen uns noch informationen. z.b:
dein rueckgabeobjekt, wie gross is dass, was macht performancetechnisch ne kopie auf podebene aus. Wenn das rausfaellt, kommt als naechstes die frgae nach threadsicherheit (bei smartpointer meist nen echtes, aber loesbares problem).
Ne andere designfrage waer zb. die erzeugung und zerstoerung die entsprechende klasse verlegen (static memberfunktionen) die erzeugerfunktion schuetzen (private) und nur ausgewaehlten objecten (parent, per friend deklaration) zugaenglich zu machen. die zerstoerung ueber eine allgemein zugaengliche destroy funktion abhandeln ....

Falls alles nicht in frage kommt, oder zusaetzlich, kann man immer noch wrappen (ne art spzialisierter smartpointer, aber mit definierten verhalten und komfortfunktionen)das der user ja nix mit zeiger zu tun hat .... smartpointer sind meist zu allegemein und auch fehlertraechtig.

Das alles must du entscheiden, was dir die sicherheit und der komfort deiner lib wert ist ....

Ciao ...

oder für meine Klassen ein MemoryManager schreiben, welches sich die dynamisch erzeugten Objecte merkt und am Ende löscht.

Äh, warum selber schreiben, wenn das schon shared_ptr macht?