Ad Delphi...Delphi wurde mal in Assembler geschrieben... Zumindest steht
das als protzig im Delphi(1)-Manual  [was ich ihnen aber auch nicht so
glaubte, hehe]

C ist IMHO (und hier zugegeben sehr IMHO  ) eine Obermenge von
C++, weil du mehr Möglichkeiten hast.C++ ist einfach in vielen Punkten
restriktiver - was ja Sinn macht....

Aber nachdem sich C++ in C transformieren
läßt (Bin mir jetzt unsicher, aber war g++ nicht gaaanz am Anfang ein C++ ->
C-Converter ???) aber C nicht in C++ (weil's dasselbe bleibt  ) ... Nun ja,
IMHO eine Frage des Blickpunktes.

IMHO bringen objektorientierte Sprachen die
saubere Kapselung der Objekte mit Members und Methoden... Nur erkenne ich oft
erst auf den 2. Blick (und mit viel gutem Willen, hehe) den Unterschied zur
Kapselung von priv. Variablen und Funktionen in Bibliotheken. IMHO lassen sich
oft (und sogar aus derselben Abstraktionsschicht) dieselben Probleme auf
demselben Weg in C lösen (wo du halt Libraries verwendest) oder in C++ (Wo du
halt Klassen verwendest).

Wobei C und C++ hier natürlich nur beliebige
Repräsentanten für Proz. vs. OO sein sollen....

Zu meinem Beispiel mit dem
C/C++-Source:In OO verwendest du oft automatisch fertige Klassen, die schon
brav optimieren - weil du es oft gar nicht anders sinnvoll realisieren kannst
(zB Java-Hashtable). Bei proz. Source mußt du halt (zB) die gnu-Bibliotheken
kennen, sonst schreibst halt schnell sinnlosen Schrott.Lernen mußt du da wie
dort zum sinnvoll Coden - hier die Klassenbibliotheken, dort die "normalen"
Libs - wobei in der proz. Welt gerne und oft die Libs nicht genutzt werden...
Leider. Insoferne bietet OO durch manche Restriktionen gerne auch oft mal
saubereren Code... Zugegeben (so eben in öfters gesehenen "Vergleichstests".
Trotz allem erscheint es logisch und einsichtig, daß VMT-Zugriffe,
late-Binding, ... Zeit kosten /müssen/ - und nicht zu knapp.Aber ich gab' eh
schon anfangs zu: Die Frage ist nur, ob das Performance-Delta Relevanz hat