C++ / Delphi
-
Das Fehlen von Mehrfachvererbung kann aber auch wieder eine bewusste Design-Entscheidung sein.
Die Ableitung von einem gemeinsamen Basisobjekt ist zwingend, wenn man mit Containern arbeiten will, in die man alle Objekte einbinden kann.
Jede Klasse deren Objekte in diesem Container abgelegt werden können sollen, muss von einer gemeinsamen Basisklasse abgeleitet werden.
Würden die Objekte nicht zwingend eine Basisklasse haben, müsste man - beim fehlen von Mehrfachvererbung - entscheiden, ob alle Klassen einer Klassenhierarchie in den Container passen sollten (dann würde die Basisklasse der Speziellen Hierarchie von TObjekt abgeleitet) oder nicht - dann würde die Basisklasse nicht von TObjekt abgeleitet und man könnte aber nicht entscheiden, dass eine Klasse irgendwo anders in besagter Hierarchie nicht doch in den Container passen würde.
Wegen der Templates in C++ kann man aber auf diese ganze Schema "Container für Elemente mit gemeinsamer Basisklasse" verzichten. Da aber Templates im grunde programmiertechnisch was ziehmlich neues sind, kann man das imho nicht als Nachteil von Delphi ggü. C++ sondern als Vorteil von C++ gegenüber den meisten anderen Sprachen sehen.
Eine gemeinsame Basisklasse ist in C++ also erstmal nicht nötig, weils Mehrfachvererbung gibt.
Seit es Templates gibt, ist aber diese ganze Technik für nen Container nicht mehr nötig. Das hat klare Vorteile (z.B. Typsicherheit).
Eine gemeinesame Basisklasse bringt einen gewissen Overhead mit. Wird die gemeinsame Basisklasse aber nicht benutzt, dürfte dieser aber eher von theoretischer Natur sein, wird sie benutzt ist das kein Overhead mehr.[ Dieser Beitrag wurde am 07.01.2003 um 16:35 Uhr von kartoffelsack editiert. ]
-
Ada hatte Anfang der 80er schon Generics, so kannste dich nicht rausreden
-
Aber so richtig bekannt geworden sind sie wohl erst seit es sie in C++ gibt.
Komisch eigentlich: ein gutes Konzept setzt sich durch, weil es in ne Sprache aufgenommen wird, anstatt dass sich ne Sprache durchsetzt, weil sie ein gutes Konzept bietet
-
Original erstellt von kartoffelsack:
Dass man die Objekte an einem Platz zusammenfasst und kein neuen Scopes aufmachen kann, ist ebenfalls ein Designmerkmal und kann nicht pauschal als Nachteil angesehen werden. Und da der Konstruktor sowieso explizit aufgerufen wird, stimmt es auch nicht, dass man so Objekte instanziiert, die man womöglich garnicht braucht.Da nicht alle Objecte einen Konstruktor haben (also die Basis Typen), verbraucht man schon Speicher, außerdem hat eine Referenz auch eine gewisse größe!
von Shade
Fuer mich wirkt ObjectPascal wie ein verzweifelter versuch pascal in eine sprache zu verwandeln die man auch in der wirtschaft verwenden kann. IMHO ist das nicht besonders gut gelungen.
Also wenn ich all das glaube, was mir Bashar von ADA erzählt hat, frag ich mich, warum die kein ADA Builder
entwickelt haben
-
aus dem gleichen Grund, warum Stroustroup kein Ada++ erfunden hat (soweit ein solches überhaupt nötig gewesen wäre)
-
Aber warum haben die dann Pascal++ erfunden? Sicher aus einem anderen Grund, aus dem Dr. Stroustrup C++ erfunden hat?
Nein, mal im ernst, ich verstehe nicht was du mir sagen willst.
-
Naja, die von AT&T fanden C ne supertolle sprache, aber ham sich gedacht, dass OO schon recht nützlich wär. Dann hat Stroustroup angefangen C um objektorientierte Elemente zu erweitern.
Die von Borland fanden (Turbo)Pascal super. Dann ham sie sich gedacht, eigentlich wär bei uns OO auch nicht schlecht und haben angefangen Pascal objektorientiert zu machen.
Beiden Sprachen kann man daher auch anmerken, dass sie eben nicht von grundauf objektorientiert entworfen sind. Und beide gehen aufgrund einer gewissen Rückwärtskompatibilität ein paar Kompromisse ein.
-
Wird das jetzt ein Warum-wurde-C++-erfolgreich?-Thread?
-
Original erstellt von Bashar:
Wird das jetzt ein Warum-wurde-C++-erfolgreich?-Thread?Ne. C++ ist deshalb erfolgreich, weils geil ist ;). Das füllt keinen Thread *G*.
-
Das ist offensichtlich kein Kriterium.
-
Original erstellt von kingruedi:
Aber warum haben die dann Pascal++ erfunden?Es ging darum, Objektorientierung, Exceptions und 'concurrency' (vertändliche Übersetztung?), also möglichst viel Buzzwords, in extendes-Pascal reinzubekommen.
ADA wurde ja mit anderen Motiven (Vereinheitlichung) entwickelt.
Bashar: Hoffentlich nicht ...
-
Wird das jetzt ein Warum-wurde-C++-erfolgreich?-Thread?
Ne, aber wir streiften die Frage, warum Borland unbedingt Pascal objektorientiert machen musste anstatt gleich ADA zu nehmen.
-
Original erstellt von Daniel E.:...
'concurrency' (vertändliche Übersetztung?)'Nebenläufigkeit' ist afaik gebräuchlich
**
ADA wurde ja mit anderen Motiven (Vereinheitlichung) entwickelt.
**.. und hat mit Pascal nicht besonders viel zu tun, von banalen Oberflächlichkeiten (siehe früher in diesem Thread, Stichworte begin/end vs. {/}, :=/= vs. =/== etc ;)) abgesehen.
-
Original erstellt von kartoffelsack:
**
Die Ableitung von einem gemeinsamen Basisobjekt ist zwingend, wenn man mit Containern arbeiten will, in die man alle Objekte einbinden kann.Jede Klasse deren Objekte in diesem Container abgelegt werden können sollen, muss von einer gemeinsamen Basisklasse abgeleitet werden.
**Warum nicht einfach Container, die TPointer (in C++: void*) enthalten?
Man könnte genauso alle Objekte in dem Container unterbringen, und hätte
eine Möglichkeit gefunden, gleichzeitig Mehrfachverebung zuzulassen.
Oder steckt da ein Denkfehler drin?
-
Oder steckt da ein Denkfehler drin?
Ja.
Das mit den Containern war nur ein Grund, das so zu machen. Man könnte das natürlich auch irgendwie mit void-Zeigern lösen. Der Punkt ist aber, dass durch die Gemeinsame Basisklasse jede Klasse eine gewisse Mindestanforderung erfüllt. Welche auch immer das sein mag (mir fällt kein wirklich gutes ein
).
-
Original erstellt von Bashar:
Inwiefern stellt das eigentlich, wie hier von einigen vertreten, einen Nachteil dar?Öhm, Speicherverschwendung vielleicht, da jedes Objekt - von welcher Klasse auch immer - die Eigenschaften, Methoden und Members(intern) von TObject erbt. Und was ist, wenn ich die garnicht brauche, was z.B. bei einer Klasse für komplexe Zahlen durchaus der Fall währe? Für mich ist das ein Nachteil.
-
hm, sollte der Compiler nicht in der Lage sein, geerbte Members, die nicht benötigt werden wegzuoptimieren?
-
Ich hoffe doch sehr dass TObject keine Datenmembers hat, sonst würde das ganze in der Tat schon leicht in Richtung Schwachsinn gehen ...
-
hat es auch nicht (glaub ich zumindest)
-
OK, hab grad mal nachgeschaut. TObject hat tatsächlich nur Methoden - keine Members.