🚀 go-pugleaf

In de.comp.lang.c++, article <1992Dec10.111912.31320@news.th-darmstadt.de>,
  schrod@iti.informatik.th-darmstadt.de (Joachim Schrod) writes:
> In article <1g5sp6INN9d9@smurf.smurf.sub.org>, urlichs@smurf.sub.org (Matthias Urlichs) writes:
> > 
> > Wenn es "was bringt" (Definition siehe oben), soll der Compiler bitteschoen
> > deine Funktion inlinen. Wenn er nur eine Implementierung findet oder die
> > Unterklassen disjunkt sind, soll der Linker den Funktionsaufruf de-
> > virtualisieren. Funktioniert in anderen Umgebungen ausgezeichnet.
> 
> Sorry, aber das ist fuer momentane (und IMHO auch zukuenftige)
> Arbeitsumgebungen Unsinn.
> 
Hmmm... Hoechstens fuer _manche_ Arbeitsumgebungen. Nicht fuer alle.

> Dort arbeitet man (ich ;-) mit shared libraries bzw. dynamisch
> nachladbaren Objekten -- der Linker weiss also nicht, ob es nicht
> doch noch eine Subklasse gibt oder in der Zukunft geben wird [sic!],
> die eine Methode redefinieren. Devirtualisierung ist von daher nicht
> erwuenscht.
> 
In einem solchen Fall darf der Linker natuerlich nichts rausoptimieren.
Das hat aber auch keiner behauptet.

Es ist klar, dass man, wenn man das Grundprinzip des statischen Programms
mit fester Objekthierarchie fallenlaesst, noch ganz andere Schweinereien
machen kann -- wer hindert mich daran, den Typ eines Objekts oder gar
die Oberklasse(n) einer ganzen Objekthierarchie zur Laufzeit zu aendern?

-- 
Matthias Urlichs  --  urlichs@smurf.sub.org -- urlichs@smurf.ira.uka.de   /(o\
Humboldtstrasse 7 -- 7500 Karlsruhe 1 -- Germany  --  +49-721-9612521     \o)/