Wie ersetzt sich ein Objekt selbst?

[vic1986]

Welche Möglichkeiten hat ein Objekt sich selbst zu ersetzen?

Ist z.B. ein platzierter new-Ausdruck in einer der Membermethoden sinnvoll?

[ghorst]

ein objekt kann sich nicht selber ersetzen. wozu brauchst du das denn?

[.filmor]

Es geht schon. Aber den gewünschten Effekt hast du nur mit der Laufzeitpolymorphie. Es muss außerdem gegeben sein, dass die Größe des neuen Typs nicht größer ist, als die des bestehenden:

class Base
{
public:
    virtual void func () = 0;
    virtual ~Base () {}
};

class A : public Base
{
public:
    template <class B>
    void transform ()
    {
        // Schauen, ob B von Base abgeleitet ist und sizeof (B) <= sizeof (A) ist
        this->~A ();
        new (this) B;
    }
};

Das ganze kann dir dann aber durchaus noch beim Destruktoraufruf um die Ohren fliegen, falls B aber von Base abgeleitet ist sollte das mit dem virtuellen Aufruf denke ich funktionieren.

[camper]

vic1986 schrieb:

Welche Möglichkeiten hat ein Objekt sich selbst zu ersetzen?

Was heißt ersetzen?

[asc]

vic1986 schrieb:

Welche Möglichkeiten hat ein Objekt sich selbst zu ersetzen?

Ist z.B. ein platzierter new-Ausdruck in einer der Membermethoden sinnvoll?

Eine weitere Alternative um Objekte austauschbar zu machen ist, eine weitere Abstraktionsebene zu verwenden (Siehe auch Entwurfsmuster Proxy/Stellvereter). Der Sinn hierbei ist, das ein Objekt dazwischen zu setzen, das nach außen hin die Schnittstelle anbietet, tatsächlich aber intern weiterdeligiert (und entsprechend leicht geändert werden kann wenn man in dem Objekt ein Zeiger austauscht).

Dies kann z.B. interessant sein wenn man große Datenobjekte verwaltet, diese aber tatsächlich erst dann einlesen will wenn man wirklich darauf zugreift.

cu André

[ronny]

.filmor: das ist ein überaus schmutziger trick, der überaus undefinierte ausganssituationen erzeugen kann - generell ist es schlecht sowas als "möglichkeit" auch nur anzuführen

die sache mit den proxy-objekten hört sich recht gut an

[.filmor]

ronny schrieb:

.filmor: das ist ein überaus schmutziger trick, der überaus undefinierte ausganssituationen erzeugen kann - generell ist es schlecht sowas als "möglichkeit" auch nur anzuführen

Nenn' mir die verletzten Sektionen im Standard. Die Schmutzigkeiten, die ich selbst schon angeführt habe kann man mit relativ wenig Aufwand zur Compilezeit abhaken.

Und abgesehen davon erfordert suspektes Design nunmal suspekte Konstrukte

[camper]

nt

[.filmor]

Wie gesagt, so funktioniert das höchstens mit dynamisch alloziierten Objekten. Das zu erzwingen ist aber auch kein Problem.

/edit: Okay, „wie gesagt“ ist gelogen, aber das meinte ich mit „Laufzeitpolymorphie“

[ghorst]

nur mal so als frage, hast du das schon mal irgendwo erfolgreich eingesetzt?

[ronny]

.filmor: der ctor kann z.b. fehlschlagen
außerdem ist es überaus unpraktisch während die methode eines objektes ausgeführt wird, dieses temporär invalid zu machen

[vic1986]

Vielen Dank an alle!

Also, Resümee der durchweg theoretischen Diskussion (mir fällt selbst kein Fall ein, in welchem man das ohne Alternative sinnvoll anwenden müsste) ist, dass es mit einem platzierten new() grundsätzlich möglich, aber nicht zu empfehlen ist, weil z.B. der Konstruktor fehlschlagen könnte.

Ich glaube mich erinnern zu können, eine ähnliche Aufgabe mal vor Jahren im Lippman gelesen zu haben. Wenn jemand das Lösungsbuch besitzt, wäre es nett zu erfahren was die dort dazu meinen.

Nochmal Danke an alle.

[.filmor]

ghorst schrieb:

nur mal so als frage, hast du das schon mal irgendwo erfolgreich eingesetzt?

Nein. Ich würde es auch nicht tun. Ich fände es grauenhaft, wenn die Objekte selbst ihren Typ ändern würden. Aber wenn ich es machen würde, dann so

ronny schrieb:

.filmor: der ctor kann z.b. fehlschlagen

Das kann dir auch in einem normalen Programm passieren. Und das kannst du hier ähnlich händeln wie dort.

ronny schrieb:

außerdem ist es überaus unpraktisch während die methode eines objektes ausgeführt wird, dieses temporär invalid zu machen

Das stimmt. Aber wenn das Programm Nebenläufigkeit hat muss man eh einen Haufen vorsichtsmaßnahmen treffen, die entsprechenden wären hier hinzuzufügen.
(Im Normalfall bekommt der Benutzer zB nicht die „echten“ virtuellen Funktionen an die Hand sondern normale Methoden. In denen könnte und sollte man dann lustig herumlocken)

[camper]

.filmor schrieb:

ronny schrieb:

.filmor: der ctor kann z.b. fehlschlagen

Das kann dir auch in einem normalen Programm passieren. Und das kannst du hier ähnlich händeln wie dort.

Auch ein fehlgeschlagener Konstruktor kann Seiteneffekte haben, am Ende lebt dann dort kein Objekt mehr. Bei normaler Konstruktion ist das kein Problem, da vorher auch kein Objekt da war, bei Konstruktion in einer Memberfunktion ist das schwieriger - denn dann muss der Handler kommunizieren, dass das jeweilige Objekt nicht mehr lebt. Mit anderen Worten: starke oder selbst schwache Exceptionsicherheit ist dann nur recht schier zu erreichen.

[asc]

.filmor schrieb:

...Ich fände es grauenhaft, wenn die Objekte selbst ihren Typ ändern würden...

Das tritt in realen Programmen aber ggf. tatsächlich auf, nur das ich nach dieser Diskussion meine Alternative (mit der Proxy-Klasse) auf jedenfall sauberer entfinde. Ja, es ist eine Indirektion mehr mag man in Hinsicht auf die Performance sagen, aber zumindestens hat es weniger Fehlerquellen...

cu André