Mal ne Frage: Wer räumt ein mit new erzeugtes, zurückgegebenes Objekt weg?
Bsp:

class Erzeuger
{
    Objekt* erzeugeObjekt(string Name) {
        return new Objekt(Name);
    }
}

int main()
{
    Objekt pObjekt;
    pObjekt = Erzeuger.erzeugeObjekt("Neu");
}

Das scheint mir doch ne Stolperfalle zu sein und ich möchte das gern sauber lösen.

Vielen Dank im Voraus

Wenn es nicht programmatisch gelöst wurde, bleibt nur ein Hinweis in der Doku oder direkt im Source.

Wenn es programmatisch gelöst werden soll, mußt du z.B. einen Garbagecollector (z.B. den bekannten von Hans Boehm) oder Smartpointer (gibts diverse für verschiedene Szenarien) benutzen.

das alte Problem

Tatsächlich. Dein Code ist weder Pseudocode noch C++.

Paul Panther schrieb:

das alte Problem

Tatsächlich. Dein Code ist weder Pseudocode noch C++.

Was denn?

finix schrieb:

Paul Panther schrieb:

das alte Problem

Tatsächlich. Dein Code ist weder Pseudocode noch C++.

Was denn?

Ja, tschuldige. Man könnte es tatsächlich als Pseudocode ansehen; Pseudocode mit relativ hässlicher Syntax, undurchsichtiger und scheinbar inkonsistenter Semantik, verwandt für eine Problemschilderung bei der höchstwahrscheinlich realer, ggf vereinfachter, Code angemessener wäre.

Was stimmt nichtmit dem Code? Ok er ist nicht vollständig..

class Erzeuger
{
    Objekt* erzeugeObjekt(string Name) {
        return new Objekt(Name);
    }
    Objekt* loescheObjekt(Objekt *obj_p) {
        delete obj_p;
    }
}

int main()
{
    Erzeuger e;
    Objekt *pObjekt;
    pObjekt = Erzeuger.erzeugeObjekt("Neu");
    Erzeuger.loescheObjekt(pObjekt);
    return 0;
}

Wichtig für delete ist, dass zur kompilierungszeit klar ist von welchem typ der übergebene Zeiger ist. Wenn du also z.B. zur Laufzeit ein Objekt aus einer library instanzierst, muss die library eine delete-funktion exportieren, da delete mit einem basis-klassen zeiger, hinter dem aber eine abgeleitete Klasse steckt, Mist baut.

[BHN]-Leberknecht schrieb:

hm, also wenn dein Erzeuger den mist in die Welt setzt, sollte das auch wieder beerdigen oder nicht?

class Erzeuger
{
    Objekt* erzeugeObjekt(string Name) {
        return new Objekt(Name);
    }
    Objekt* loescheObjekt(Objekt *obj_p) {
        delete obj_p;
    }
}

int main()
{
    Erzeuger e;
    Objekt *pObjekt;
    pObjekt = Erzeuger.erzeugeObjekt("Neu");
    Erzeuger.loescheObjekt(pObjekt);
    return 0;
}

Wichtig für delete ist, dass zur kompilierungszeit klar ist von welchem typ der übergebene Zeiger ist. Wenn du also z.B. zur Laufzeit ein Objekt aus einer library instanzierst, muss die library eine delete-funktion exportieren, da delete mit einem basis-klassen zeiger, hinter dem aber eine abgeleitete Klasse steckt, Mist baut.

Wichtig für delete ist, dass zur kompilierungszeit klar ist von welchem typ der übergebene Zeiger ist. Wenn du also z.B. zur Laufzeit ein Objekt aus einer library instanzierst, muss die library eine delete-funktion exportieren, da delete mit einem basis-klassen zeiger, hinter dem aber eine abgeleitete Klasse steckt, Mist baut.

EDIT:

Du willst also sagen das folgendes "mist" ist? Oder versteh ich da was falsch?

class base {};

class derived : public base {};

int main() {
  base *obj = new derived;

  delete obj;
}

Was ist denn das fürn Mist?
Dann kann ich auch direkt nen delete aufrufen...
Also ich würd ein

std::auto_ptr<Objekt*> erzeugeObjekt(string Name);

daraus machen, wie Arschi gesagt hat.

Je nach Verwendung auch ein shared_ptr (Gruß an CStoll ).

Aber die beste Möglichkeit dürften wohl die erwähnten Smart-Pointer sein, um die Aufräumarbeiten zu koordinieren.

Erzeuger.loescheObjekt(pObjekt);

Was ist denn das fürn Mist?
Dann kann ich auch direkt nen delete aufrufen...
Also ich würd ein

std::auto_ptr<Objekt*> erzeugeObjekt(string Name);

daraus machen, wie Arschi gesagt hat.

Je nach Verwendung auch ein shared_ptr (Gruß an CStoll ).

Das Problem ist, das ein Aufrufer nicht wissen kann, was eine erzeuge()-Funktion alles macht. Vielleicht allokiert er externe Ressourcen und bindet sie an das zurückgegebene Objekt ... und die muß er hinterher wieder freigeben.
Oder die Daten werden in einer DB abgelegt (und auch dort gelöscht). Oder ...

Für den hier erwähnten trivialen Fall (in dem tatsächlich ein delete (sei es manuelle oder per auto_ptr) reichte) würde ja wohl auch kaum jemand einen externen Erzeuger bauen, oder ?

Ich stimme jedenfalls Leberknechts Vorschlag zu: Bietet eine API eine "Quelle" an, sollte sie tunlichst auch eine "Senke" anbieten.
Noch lieber würde ich allerdings auf "Erzeuger/Vernichter" verzichten...

Gruß,

Simon2.

Das Problem ist, das ein Aufrufer nicht wissen kann, was eine erzeuge()-Funktion alles macht. Vielleicht allokiert er externe Ressourcen und bindet sie an das zurückgegebene Objekt ... und die muß er hinterher wieder freigeben.
Oder die Daten werden in einer DB abgelegt (und auch dort gelöscht). Oder ...

Dafür ist dann ein Destruktor zuständig. Notfalls gebe ich ein Proxyobjekt zurück, wenn ich ressourcen binde, wo ich den Operator-> überlade. Sowas wie Erzeuger.loescheObjekt(pObjekt) brauche ich in C++ ganz sicher nicht. Einfach mal in "Modernes C++ Design" unter Proxy-Objekt nachschauen. Kann man zumindest die Idee "klauen".

Dafür ist dann ein Destruktor zuständig. Notfalls gebe ich ein Proxyobjekt zurück, wenn ich ressourcen binde, wo ich den Operator-> überlade. Sowas wie Erzeuger.loescheObjekt(pObjekt) brauche ich in C++ ganz sicher nicht. Einfach mal in "Modernes C++ Design" unter Proxy-Objekt nachschauen. Kann man zumindest die Idee "klauen".

aber manchmal ist eine zigarre bloß eine zigarre.
daß man passend zur quelle eine senke baut, ist schon ok. da kannste dann drumherum mit proxies spielen. das stört keinen.

Das Problem ist, das ein Aufrufer nicht wissen kann, was eine erzeuge()-Funktion alles macht. Vielleicht allokiert er externe Ressourcen und bindet sie an das zurückgegebene Objekt ... und die muß er hinterher wieder freigeben.
Oder die Daten werden in einer DB abgelegt (und auch dort gelöscht). Oder ...

Dafür ist dann ein Destruktor zuständig. Notfalls gebe ich ein Proxyobjekt zurück, wenn ich ressourcen binde, wo ich den Operator-> überlade. Sowas wie Erzeuger.loescheObjekt(pObjekt) brauche ich in C++ ganz sicher nicht. Einfach mal in "Modernes C++ Design" unter Proxy-Objekt nachschauen. Kann man zumindest die Idee "klauen".

wie ich schon sage:
Erste Wahl ist, dass man ohne Erzeuger/Vernichter auskommt - und genau das ist der Fall, wenn man die Funktionalität sinnvoll in die Klasse reinprogrammieren kann (Ctor/DTor).

WENN man aber nicht darum herumkommt, Erzeuger/Vernichter zu nutzen, sollte man ein Objekt nicht einfach deleten (als Nutzer) bzw. einen geeigneten Vernichter zur Verfügung stellen (als Implementierer).

Gruß,

Simon2.

wie ich schon sage:
Erste Wahl ist, dass man ohne Erzeuger/Vernichter auskommt - und genau das ist der Fall, wenn man die Funktionalität sinnvoll in die Klasse reinprogrammieren kann (Ctor/DTor).

Geht nicht, wenn man ne Abstract Factory und für Polymorphismus wirds auch schwieriger.

Simon2 schrieb:

WENN man aber nicht darum herumkommt, Erzeuger/Vernichter zu nutzen, sollte man ein Objekt nicht einfach deleten (als Nutzer) bzw. einen geeigneten Vernichter zur Verfügung stellen (als Implementierer).

Leuchtet ein