Wie ersetzt sich ein Objekt selbst?
-
.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
-
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
-
nt
-
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“
-
nur mal so als frage, hast du das schon mal irgendwo erfolgreich eingesetzt?
-
.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
-
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.
-
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)
-
.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.
-
.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é