HDTenEightyP/NetNews huggingface dataset:
From: hf@tk.telematik.informatik.uni-karlsruhe.de (Harald Fuchs)
Newsgroups: de.comp.lang.c++
Subject: Re: Lippmann - was ist das?
Date: 15 Dec 92 13:58:59
Organization: Karlsruhe University, Germany
	<HF.92Dec13113953@whyaduck.tk.telematik.informatik.uni-karlsruhe.de>
	<1gkcsjINNrm4@smurf.smurf.sub.org>
NNTP-Posting-Host: whyaduck.telematik.informatik.uni-karlsruhe.de
In-reply-to: urlichs@smurf.sub.org's message of 15 Dec 1992 11:43:31 +0100

In article <1gkcsjINNrm4@smurf.smurf.sub.org>, urlichs@smurf.sub.org (Matthias Urlichs) writes:

> Genausogut (und meiner Meinung nach sinnvoller) kann ich die Sprache so
> definieren, dass sie generell von dynamischer Bindung ausgeht.

Schon wieder so einer, der aus C++ ein zweites Eiffel oder Trellis
machen will :-)

Jede Art von dynamischer Bindung (egal ob ber vtbl oder nicht) kostet
ein paar Taktzyklen mehr und macht die entsprechenden Objekte ein
bichen grer, und deshalb ist eben statische Bindung der Default.

Wenn Du dynamische Bindung als Default haben willst, mut Du
konsequenterweise auch verlangen, da Objekte nur ber Referenzen oder
Pointer angesprochen werden, und das ist der Schritt von "C++" zu "D".

Das von Dir erwhnte Wrtchen "sinnvoller" bezieht sich auf die reine
OO-Lehre und ist deswegen im Kontext von C++ mit Vorsicht zu genieen.
--

Harald Fuchs <hf@telematik.informatik.uni-karlsruhe.de>
Newsgroups: de.comp.lang.c++
From: hasko@heeg.de (Hasko Heinecke)
Subject: Re: Lippmann - was ist das?
Organization: Georg Heeg Objektorientierte Systeme, Dortmund, FRG
Date: Thu, 17 Dec 1992 16:14:56 GMT

In article <1gll29INNqb8@smurf.smurf.sub.org> urlichs@smurf.sub.org (Matthias Urlichs) writes:
>Ausserdem koennte ein noch _etwas_ intelligenterer Compiler auch Zuweisungen
>von Pointer-auf-B an Pointer-auf-A (A sei die Oberklasse von B) markieren.
>Wenn es solche nicht gibt, brauchen wir auch keine dynamische Bindung.
>
>(Bevor jetzt wieder jemand meckert: Mir ist auch klar, dass man das nicht
>zu 100% erkennen kann, und unter C++ schon gleich gar nicht. Aber eine
>95%-Loesung wuerde in den meisten real auftretenden Faellen funktionieren,
>und fuer den Rest (oder fuer dumme Compiler) schreiben wir das "virtual"
>eben zur Klasse. Nicht zur Funktion, denn da hat es meiner Meinung nach
>wirklich ncihts zu suchen.)

Das Problem ist, dass man nicht im Voraus erkennen kann, wo's schiefgehen
wird. Ehrlich, frag Turing... :-)

>> Das von Dir erwaehnte Woertchen "sinnvoller" bezieht sich auf die reine
>> OO-Lehre und ist deswegen im Kontext von C++ mit Vorsicht zu geniessen.
>
>Umgekehrt -- C++ an sich ist mit Vorsicht zu geniessen.  :-)

Korrekt.

Hasko

-- 
+-------------------------------------------------------+
| Hasko Heinecke @ Georg Heeg Objektorientierte Systeme |
| I _never_ mean what I say - and nobody else does...   |
+-------------------------------------------------------+
Newsgroups: de.comp.lang.c++
From: loewis@informatik.hu-berlin.de (M.v.Loewis)
Subject: Re: Objectidentifer (was: Re: Lippmann - was ist das?)
Organization: Humboldt University Berlin, Department of Computer Science
Date: Wed, 16 Dec 1992 12:02:43 GMT

In <vaillant.724087013@rama> vaillant@rama.informatik.rwth-aachen.de (Stefan Vaillant) writes:

>Catell stellt zwei Forderungen auf:
>  1) OID's muessen vom System generiert werden.
>  2) die generierten OID's aller existierenden Objekte
>     muessen verschieden sein.


Ich wuerde mir zusaetzlich folgendes wuenschen:
   3) Die Gueltigkeit einer OID soll entweder implizit gesichert,
      oder explizit feststellbar sein.
In diesem Sinne ist ein Pointer als OID nicht "schoen", da man weder sichern
kann, dass irgendeine Bitkombination nicht versehentlich als Pointer inter-
pretiert wird (beispielsweise weil das referenzierte Objekt schon nicht mehr
existiert), noch kann man explizit feststellen, ob ein Pointer auf ein
Objekt zeigt oder "in die Wueste".


Martin
From: hf@tk.telematik.informatik.uni-karlsruhe.de (Harald Fuchs)
Newsgroups: de.comp.lang.c++
Subject: Re: Lippmann - was ist das?
Date: 16 Dec 92 13:55:03
Organization: Karlsruhe University, Germany
	<1gkcsjINNrm4@smurf.smurf.sub.org>
	<HF.92Dec15135859@whyaduck.tk.telematik.informatik.uni-karlsruhe.de>
	<1gll29INNqb8@smurf.smurf.sub.org>
NNTP-Posting-Host: whyaduck.telematik.informatik.uni-karlsruhe.de
In-reply-to: urlichs@smurf.sub.org's message of 15 Dec 1992 23:09:13 +0100

In article <1gll29INNqb8@smurf.smurf.sub.org>, urlichs@smurf.sub.org (Matthias Urlichs) writes:

>> Jede Art von dynamischer Bindung (egal ob ueber vtbl oder nicht) kostet
>> ein paar Taktzyklen mehr und macht die entsprechenden Objekte ein
>> bisschen groesser, und deshalb ist eben statische Bindung der Default.

> Ausser das Programm ist so strukturiert und der Compiler+Linker so
> intelligent, dass die dynamische Bindung wieder rausfliegt.

Er nu wieder... wenn wir dynamische Bindung zum Default machen (theoretisch
durchaus sinnvoll), gibt es also zwei moegliche Konsequenzen:
1. die Programme laufen halt viel langsamer, oder
2. wir brauchen eine superschlaue Entwicklungsumgebung
Beides haette C++ das Schicksal von Eiffel, Trellis und vermutlich auch Beta
beschert: im Elfenbeinturm hoch angesehen, oft zitiert und ungeheuer
einflussreich, aber eben kein stupider Winzelweich-Compiler fuer Bitty-Boxen
unter MurksDoof.

> Meiner Erfahrung nach trifft das fuer einen grossen Teil der Spielobjekte,
> d.h. derer die sowieso nicht verfeinnert werden, sowieso zu.

Richtig.

> Ausserdem koennte ein noch _etwas_ intelligenterer Compiler auch Zuweisungen
> von Pointer-auf-B an Pointer-auf-A (A sei die Oberklasse von B) markieren.

Aha, tagged pointers? Also vptr durch die Hintertuer?

> (Bevor jetzt wieder jemand meckert: ...

Okay, ich bin ja schon still.

>> Wenn Du dynamische Bindung als Default haben willst, musst Du
>> konsequenterweise auch verlangen, dass Objekte nur ueber Referenzen oder
>> Pointer angesprochen werden, und das ist der Schritt von "C++" zu "D".

> Wieso? Bei direkten Objekten (oder wie auch immer das in C++ heisst) 
> ist statisch == dynamisch. Fein. Ein Problem weniger.  :-)

Nicht so schnell. Wenn Du ein Objekt direkt ansprichst (C++ kennt keinen
Terminus dafuer), _kannst_ Du ueberhaupt nicht dynamisch binden. Dasselbe ist
der Fall, wenn wir im real existierenden C++ das Woertchen "virtual" weglassen
- und damit befinden wir uns wieder am Ausgangspunkt der Diskussion.

> Umgekehrt -- C++ an sich ist mit Vorsicht zu geniessen.  :-)

Nur wenn man seinen Stroustrup nicht gelesen hat:
  C++ is a general purpose programming language designed to make programming
  more enjoyable for the serious programmer.
Damit meint Bjarne vermutlich ebenso schraege Hacker wie er selbst und seine
Kollegen im Hacker-Refugium der Bell Labs. Ganz sicher meint er keine
Bertrand-Meyer-Fans :-)

> Da saeuft man nun Tag fuer Tag - und keiner dankt es einem.

Wieso? Mein Kneipenwirt schaut immer sehr zufrieden drein...
--

Harald Fuchs <hf@telematik.informatik.uni-karlsruhe.de>
Newsgroups: de.comp.lang.c++
From: hasko@heeg.de (Hasko Heinecke)
Subject: Re: Objectidentifer (was: Re: Lippmann - was ist das?)
Organization: Georg Heeg Objektorientierte Systeme, Dortmund, FRG
Date: Mon, 14 Dec 1992 13:45:12 GMT

In article <vaillant.724087013@rama> vaillant@rama.informatik.rwth-aachen.de (Stefan Vaillant) writes:
>Wie definierst Du denn den Begriff "Objektidentitaet"(OID)?
>Wenn Du nicht Pointerwerte als OID's verwendest, was dann?
>
>
>Die mir bekannten Definitionen von Objektidentitaet vertragen sich alle
>mit C++-Zeigern:
>  Khoshafian Copeland: "Identity is that property of an object which 
>                        distinguishes it from all other object"
>oder [besser]
>  Catell/ODM: "Object identity: Objects can have a unique identity
>               independent of the values that they contain."
>Catell stellt zwei Forderungen auf:
>  1) OID's muessen vom System generiert werden.
>  2) die generierten OID's aller existierenden Objekte
>     muessen verschieden sein.

Tja, und was passiert in verteilten Anwendungen, die auf mehreren Rechnern
mit lokalem Speicher laufen? Oder bei Client/Server-Anwendungen bei
virtueller Adressierung?

In beiden Faellen identifiziert ein Pointer, d.h. eine Adresse in einem
virtuellen Speicherbereich auf einer Maschine ein Objekt nicht eindeutig.

Hasko

-- 
+-------------------------------------------------------+
| Hasko Heinecke @ Georg Heeg Objektorientierte Systeme |
| I _never_ mean what I say - and nobody else does...   |
+-------------------------------------------------------+
Newsgroups: de.comp.lang.c++
From: schrod@iti.informatik.th-darmstadt.de (Joachim Schrod)
Subject: Re: Lippmann - was ist das?
Date: Thu, 17 Dec 1992 18:09:54 GMT
Organization: TU Darmstadt

In article <HF.92Dec16135503@whyaduck.tk.telematik.informatik.uni-karlsruhe.de>, hf@tk.telematik.informatik.uni-karlsruhe.de (Harald Fuchs) writes:
> In article <1gll29INNqb8@smurf.smurf.sub.org>, urlichs@smurf.sub.org (Matthias Urlichs) writes:
> 
> >> Jede Art von dynamischer Bindung (egal ob ueber vtbl oder nicht) kostet
> >> ein paar Taktzyklen mehr und macht die entsprechenden Objekte ein
> >> bisschen groesser, und deshalb ist eben statische Bindung der Default.
> 
> > Ausser das Programm ist so strukturiert und der Compiler+Linker so
> > intelligent, dass die dynamische Bindung wieder rausfliegt.
> 
> Er nu wieder... wenn wir dynamische Bindung zum Default machen (theoretisch
> durchaus sinnvoll), gibt es also zwei moegliche Konsequenzen:
> 1. die Programme laufen halt viel langsamer, oder
> 2. wir brauchen eine superschlaue Entwicklungsumgebung

oder
  3. Man muss die `Devirtualisierung' per Hand angeben.

	So wie man z.Zt. eben virtual hinschreibt, schreibt man dann
   `concrete' oder so was davor. (Ob vor die gesamte Klasse oder vor
   jede Funktion einzeln, ist mir dabei ziemlich egal.)
   	Das wuerde mit Sicherheit einigen Studenten hier, die haeufig
   das virtual vor dem Destruktor vergessen, einige Debugging-Zeit
   sparen. (Ich bin ein gebranntes Kind -- ich musste beim letzten Mal
   den Kurs halten und die Fragen beantworten... ;-)


Wobei uebrigens die Diskussion ``virtuelle Funktionen per Default
oder nicht'' an meinen Problemen mit C++ (IMHO viel wichtiger :)
vorbeigehen: Das virtual steht einfach in meinen
(Editor-)Klassentemplates drin und fertig.
    Ich faende einen ordentlichen Garbage Collector viel wichtiger.
Es gibt ein paar, die aber nicht so 100%ig benutzbar sind. Im
C++-Archiv in Darmstadt [*] findet man im class-libraries/misc/
Directory den von DEC. OATH ist auch ein guter Ansatz (im Directory
nebendran).

[*] per anonymous ftp

	ftp.th-darmstadt.de [130.83.55.75]
	directory pub/programming/languages/C++

Dort findet man die meisten frei verteilbaren Klassenbibliotheken,
Entwicklungstools, etwas Doku (Programming Guidelines,
Produkte-Katalog), Beispiele aus Buechern, etc.
    mail server gibt's noch keinen, sehrwahrscheinlich aber naechstes
Jahr. Wenn jemand aus dem Subnet per ftp-mailer etwas ordert, sollte
er sich vorher ein Listing anfordern -- die Archive sind teilweise
*sehr* gross.

Enjoy.

--
Joachim

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod			Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
From: martin@mwtech.UUCP (Martin Weitzel)
Newsgroups: de.comp.lang.c++
Subject: Re: Lippmann - was ist das?
Date: 20 Dec 92 17:40:42 GMT
Reply-To: martin@mwtech.UUCP (Martin Weitzel)
Organization: MIKROS Systemware, Darmstadt/W-Germany

In article <HF.92Dec13113953@whyaduck.tk.telematik.informatik.uni-karlsruhe.de> hf@tk.telematik.informatik.uni-karlsruhe.de (Harald Fuchs) writes:
>In article <1362@mwtech.UUCP>, martin@mwtech.UUCP (Martin Weitzel) writes:
>
[Kritik am C++-Sprachdesign / hier: explizit erforderliche Virtualisierung]
>
>Der Vergleich hinkt. "register" kann man ignorieren, ohne was an der
>Semantik eines Programms zu aendern; "virtual" hingegen nicht:

[...Beispiel geloescht ...]

>Es ist zwar anzunehmen, dass der Anwender an dieser Stelle dynamische
>Bindung will, aber die Sprachdefinition erfordert statische Bindung.

Richtig.  Aber es ist einem Compiler unbenommen, hier eine Warnung
auszugeben, genau wie ein Compiler bei zehn vergebenen Register-Attributen
warnen darf, dass er vier davon nicht beruecksichtigt, weil die CPU z.B.
nur ueber sechs freie Register verfuegt.

Meine Behauptung ist einfach die:  Wenn eine Sprache "Hinweise" erlaubt,
die "eigentlich" nicht notwendig sind, weil andere Sprachen die Sache
selbst optimal entscheiden koennen, dann kann eine Qualitaets-Implemention
nach den gleichen Kriterien wie diese anderen Sprachen ueber auszugebende
Warnungen entscheiden.  Dies ist in gewisser Weise zwar eine "Nachbesserung"
am Design der Sprache, aber ich bin gerne bereit, das in Kauf zu nehmen, um
die Kompatibiltaet zu aelterer Software zu erhalten.  Sicher waere es besser,
wenn "virtual" der Default waere, genauso wie globale Variable in C besser
per Default "static" waeren, aber die Probleme, die dies verursacht, sind
IMHO nicht so gravierend, dass man deshalb von C++ Abstand nehmen muesste
zugunsten einer ganz anderen OOP-Sprache.
-- 
Martin Weitzel, email: martin@mwtech.UUCP, voice: 49-(0)6151-6 56 83
Newsgroups: de.comp.lang.c++
From: hasko@heeg.de (Hasko Heinecke)
Subject: Re: Lippmann - was ist das?
Organization: Georg Heeg Objektorientierte Systeme, Dortmund, FRG
Date: Thu, 17 Dec 1992 16:12:23 GMT

In article <HF.92Dec15135859@whyaduck.tk.telematik.informatik.uni-karlsruhe.de> hf@tk.telematik.informatik.uni-karlsruhe.de (Harald Fuchs) writes:
>In article <1gkcsjINNrm4@smurf.smurf.sub.org>, urlichs@smurf.sub.org (Matthias Urlichs) writes:
>
>> Genausogut (und meiner Meinung nach sinnvoller) kann ich die Sprache so
>> definieren, dass sie generell von dynamischer Bindung ausgeht.
>
>Schon wieder so einer, der aus C++ ein zweites Eiffel oder Trellis
>machen will :-)
>
>Jede Art von dynamischer Bindung (egal ob ber vtbl oder nicht) kostet
>ein paar Taktzyklen mehr und macht die entsprechenden Objekte ein
>bichen grer, und deshalb ist eben statische Bindung der Default.
>
>Wenn Du dynamische Bindung als Default haben willst, mut Du
>konsequenterweise auch verlangen, da Objekte nur ber Referenzen oder
>Pointer angesprochen werden, und das ist der Schritt von "C++" zu "D".
>
>Das von Dir erwhnte Wrtchen "sinnvoller" bezieht sich auf die reine
>OO-Lehre und ist deswegen im Kontext von C++ mit Vorsicht zu genieen.

Worueber reden wir hier eigentlich? Reden wir ueber vereinfachte
Analyse/Design/Implementation/Dokumetation/Wartung-Zyklen oder ueber
Taktzyklen? Wer kuemmert sich denn heute noch ernsthaft um einzelne
Taktzyklen, ausser ganz wenigen hardwarenahen Entwicklern. Und 
hardwarenah heisst hier: Realtime-Signalverarbeitung zum Beispiel,
nicht Programmierung von VGA-Karten.

Hasko

-- 
+-------------------------------------------------------+
| Hasko Heinecke @ Georg Heeg Objektorientierte Systeme |
| I _never_ mean what I say - and nobody else does...   |
+-------------------------------------------------------+
From: urlichs@smurf.sub.org (Matthias Urlichs)
Newsgroups: de.comp.lang.c++
Subject: Re: Lippmann - was ist das?
Date: 15 Dec 1992 23:09:13 +0100
Organization: University of Karlsruhe, FRG
NNTP-Posting-Host: 127.0.0.1

In de.comp.lang.c++, article <HF.92Dec15135859@whyaduck.tk.telematik.informatik.uni-karlsruhe.de>,
  hf@tk.telematik.informatik.uni-karlsruhe.de (Harald Fuchs) writes:
> In article <1gkcsjINNrm4@smurf.smurf.sub.org>, urlichs@smurf.sub.org (Matthias Urlichs) writes:
> 
> > Genausogut (und meiner Meinung nach sinnvoller) kann ich die Sprache so
> > definieren, dass sie generell von dynamischer Bindung ausgeht.
> 
> Schon wieder so einer, der aus C++ ein zweites Eiffel oder Trellis
> machen will :-)
> 
Nein, aber...

> Jede Art von dynamischer Bindung (egal ob ueber vtbl oder nicht) kostet
> ein paar Taktzyklen mehr und macht die entsprechenden Objekte ein
> bisschen groesser, und deshalb ist eben statische Bindung der Default.
> 
Ausser das Programm ist so strukturiert und der Compiler+Linker so
intelligent, dass die dynamische Bindung wieder rausfliegt.

Meiner Erfahrung nach trifft das fuer einen grossen Teil der Spielobjekte,
d.h. derer die sowieso nicht verfeinnert werden, sowieso zu.

Ausserdem koennte ein noch _etwas_ intelligenterer Compiler auch Zuweisungen
von Pointer-auf-B an Pointer-auf-A (A sei die Oberklasse von B) markieren.
Wenn es solche nicht gibt, brauchen wir auch keine dynamische Bindung.

(Bevor jetzt wieder jemand meckert: Mir ist auch klar, dass man das nicht
zu 100% erkennen kann, und unter C++ schon gleich gar nicht. Aber eine
95%-Loesung wuerde in den meisten real auftretenden Faellen funktionieren,
und fuer den Rest (oder fuer dumme Compiler) schreiben wir das "virtual"
eben zur Klasse. Nicht zur Funktion, denn da hat es meiner Meinung nach
wirklich ncihts zu suchen.)

> Wenn Du dynamische Bindung als Default haben willst, musst Du
> konsequenterweise auch verlangen, dass Objekte nur ueber Referenzen oder
> Pointer angesprochen werden, und das ist der Schritt von "C++" zu "D".

Wieso? Bei direkten Objekten (oder wie auch immer das in C++ heisst) 
ist statisch == dynamisch. Fein. Ein Problem weniger.  :-)
> 
> Das von Dir erwaehnte Woertchen "sinnvoller" bezieht sich auf die reine
> OO-Lehre und ist deswegen im Kontext von C++ mit Vorsicht zu geniessen.

Umgekehrt -- C++ an sich ist mit Vorsicht zu geniessen.  :-)

-- 
Da saeuft man nun Tag fuer Tag - und keiner dankt es einem.
-- 
Matthias Urlichs  --  urlichs@smurf.sub.org -- urlichs@smurf.ira.uka.de   /(o\
Humboldtstrasse 7 -- 7500 Karlsruhe 1 -- Germany  --  +49-721-9612521     \o)/
From: urlichs@smurf.sub.org (Matthias Urlichs)
Newsgroups: de.comp.lang.c++
Subject: Re: Lippmann - was ist das?
Date: 13 Dec 1992 14:25:25 +0100
Organization: University of Karlsruhe, FRG
NNTP-Posting-Host: 127.0.0.1

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)/
From: hf@tk.telematik.informatik.uni-karlsruhe.de (Harald Fuchs)
Newsgroups: de.comp.lang.c++
Subject: Re: Lippmann - was ist das?
Date: 13 Dec 92 11:39:53
Organization: Karlsruhe University, Germany
	<1g5sp6INN9d9@smurf.smurf.sub.org> <1362@mwtech.UUCP>
NNTP-Posting-Host: whyaduck.telematik.informatik.uni-karlsruhe.de
In-reply-to: martin@mwtech.UUCP's message of 11 Dec 92 16:55:17 GMT

In article <1362@mwtech.UUCP>, martin@mwtech.UUCP (Martin Weitzel) writes:

> Da sehe ich mich eigentlich nur bestaetigt (ich nehme an, das wolltest Du
> auch).  Um es anders auszudruecken:  IMHO liegen Leute, die wegen der
> Moeglichkeit der falschen Verwendung von "virtual" und/oder "inline"
> das *Design* von C++ kritisieren, ebenso falsch wie Leute, die das Design
> von C (ohne ++) kritisieren, weil es da die "register"-Vereinbarung gibt
> und kein Mensch doch wissen koenne, welche Variablen man denn am besten
> in Register lege (u.a. weil man in einem portablen Programm garnicht weiss,
> wieviele Register es gibt), und dass es besser sei, wenn der Compiler das
> selbst entscheiden wuerde.  (Fuer die uninformierten Leser:  Fast alle
> *heutigen* C-Compiler machen genau diese Optimierungen von sich aus und
> ignorieren den Zusatz "register" bei der Vereinbarung einfach.)

Der Vergleich hinkt. "register" kann man ignorieren, ohne was an der
Semantik eines Programms zu aendern; "virtual" hingegen nicht:

  struct A {
    /*virtual*/ void f () { cout << "A::f\n"; }
  };

  struct B: A {
    void f () { cout << "B::f\n"; }
  };

  main () {
    A* p = new B;
    p->f ();
  }

Es ist zwar anzunehmen, dass der Anwender an dieser Stelle dynamische
Bindung will, aber die Sprachdefinition erfordert statische Bindung.
--

Harald Fuchs <hf@telematik.informatik.uni-karlsruhe.de>
From: urlichs@smurf.sub.org (Matthias Urlichs)
Newsgroups: de.comp.lang.c++
Subject: Re: Lippmann - was ist das?
Date: 15 Dec 1992 11:43:31 +0100
Organization: University of Karlsruhe, FRG
NNTP-Posting-Host: 127.0.0.1

In de.comp.lang.c++, article <HF.92Dec13113953@whyaduck.tk.telematik.informatik.uni-karlsruhe.de>,
  hf@tk.telematik.informatik.uni-karlsruhe.de (Harald Fuchs) writes:
> 
> Der Vergleich hinkt. "register" kann man ignorieren, ohne was an der
> Semantik eines Programms zu aendern; "virtual" hingegen nicht:
> 
>   struct A {
>     /*virtual*/ void f () { cout << "A::f\n"; }
>   };
> 
>   struct B: A {
>     void f () { cout << "B::f\n"; }
>   };
> 
>   main () {
>     A* p = new B;
>     p->f ();
>   }
> 
> Es ist zwar anzunehmen, dass der Anwender an dieser Stelle dynamische
> Bindung will, aber die Sprachdefinition erfordert statische Bindung.

Das ist aber ein Problem der Sprachdefinition.

Genausogut (und meiner Meinung nach sinnvoller) kann ich die Sprache so
definieren, dass sie generell von dynamischer Bindung ausgeht. Wenn ich 
eine bestimmte statische Variante haben will, muss ich die dann eben explizit
aufrufen -- geht in C++ schliesslich ohne Probleme.
Das haette dann auch den Vorteil, dass im genannten Beispiel explizit
p->A::f() (oder so aehnlich) stehen wuerde und der menschliche Debugger :-)
nicht stundenlang rumraetseln muss, wieso jetzt A::f und nicht B::f aufge-
rufen wurde.

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