C++ / Delphi
-
Ok, eine etwas eigentümliche Vorstellung von Klassen aus Sicht von C++.
In C++ wird vorausgesetzt, dass jede Klasse diese Eigenschaften automatisch
besitzt. Aber vertretbar ist es.... obwohl es mir ein wenig quer liegt
[ Dieser Beitrag wurde am 06.01.2003 um 20:55 Uhr von Taurin editiert. ]
-
Darüber kann man sich streiten, ich denke beides ist nur reine Gewohnheitssache.
Es ist trotzdem unkomfortabel, der C Standard wurde ja auch nicht umsonst geändert um zu ermöglichen, dass man überall Variablen definieren kann, wie man will
Objekte werden in Delphi, eh dynamisch erstellt.
WAS! Kein wunder, dass Delphi so laaaaaannngsaam ist Naja da wär es wohl Performanter Speicher für alle Objekte in einem Block zu belegen.Ich glaube, es wird besser für dich sein, wenn du hier deinen Mund hältst, denn wie du siehst, wissen alle hier besser bescheid als du.
Wir sind doch alle groß und alt und müssen uns nicht angreifen!
http://community.borland.com/soapbox/techvoyage/article/1,1795,10280,00.htm#5.0
Das man 3 Möglichkeiten für Kommentare hat finde ich übrigens gar nicht schlecht, weil ich mit { } Code auskommentiere (*
brauch ich für längere Kommentare und // für kurze, dass hat den Vorteil, dass ich nicht wie bei C(++) leicht mit den /**/ in Bedrängniss komme/* blabla(); /* foo */ bar(); */@Luckie
In so fern ist es logisch, dass beide von TObject abstammen. Und genau das haben sie auch gemeinsam.
Das ist eben der billige Trick von O Programmisprachen, die keine Templates besitzen (von wegen Typ Sicherheit!)
BTW.
Ist Object Pascal eigentlich proprietär oder gibt es da einen Standard oä.?[ Dieser Beitrag wurde am 06.01.2003 um 20:59 Uhr von kingruedi editiert. ]
-
Original erstellt von kingruedi:
**
Ist Object Pascal eigentlich proprietär oder gibt es da einen Standard oä.?
**Soweit ich weiß ist Object Pascal eine reine Borlandangelegenheit. Insofern
wird es (vermutlich) nur einen privaten Borlandstandard gegeben oder so.
-
Hallo,
dass Delphi so laaaaaannngsaam ist
Die angeblichen Geschwindigkeitsnachteile von Delphi sind Gerüchte. ObjectPascal schneidet im Geschwindigkeitstest mit C++, als beinahe gleichschnell ab (kein wunder zu Zeiten von HochOptimierung)
Naja da wär es wohl Performanter Speicher für alle Objekte in einem Block zu reservieren
Scherzbold
Das ist eben der billige Trick von O Programmisprachen, die keine Templates besitzen (von wegen Typ Sicherheit!)
Was für ein billiger Trick ?!
mfg
Th3Law
-
Original erstellt von Th3Law:
Die angeblichen Geschwindigkeitsnachteile von Delphi sind Gerüchte. ObjectPascal schneidet im Geschwindigkeitstest mit C++, als beinahe gleichschnell ab (kein wunder zu Zeiten von HochOptimierung)Hast du schon mal versucht, DirectDraw oder Direct3D Programme in Delphi
umzusetzten??? Trotz DelphiX wird das hier nicht mehr viel mit Delphi...
-
Original erstellt von Th3Law:
Was für ein billiger Trick ?!Na zB:
vector<foo>
ist dann ein
ObjectVector
und beinhaltet referenzen/zeiger auf TObjects - dh man kann es wie einen vector<foo> verwenden.
dirty hackgenerische Programmierung ist sehr maechtig. Warum schreien denn Java und .NET Entwickler nach Templates?
variablen am anfang einer funktion zu deklarieren ist nicht nur out sondern auch unpraktisch.
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. Haette Delphi nicht die VCL wuerde es wohl kaum jemand verwenden. Und Delphi hat IMHO auch nur den Plusplunkt, dass es gratis ist - sonst sehe ich keinen sinn warum man nicht gleich den BCB nehmen sollte.
-
Die Diskussion, ob begin oder { oder wie die for-Schleifen genau arbeiten soll ist ziehmlich lächerlich, weil Geschmackssache.
Begin und { macht ja wohl null Unterschied außer vielleicht bei der Tipparbeit, wobei ich begin genausoschnell getippt hab wie AlgGr-7 zu drücken.
Die schleifen ist auch wurscht, weil es für jede möglichkeit sich entsprechende schleifenkonstrukte gibt.
Ich kenn mich jetzt nicht so gut in Delphi aus, hab aber früher einiges Object-Pascal programmiert. Soweit ich mich erinnere, müssen NICHT alle Klassen von einem Objekt abgeleitet sein. TObject ist das Basisobject für die VCL, für andere Bibliotheken ist das aber in keinster weise zwingen. In den MFC sind auch alle Klassen von CObject abgeleitet.
Dass alle Objekte Referenzen sind, ist eine bewusste Designentscheidung der Entwickler von Object-Pascal. Das ist auch in anderen OO-Sprachen so (Java). In C++ nicht, deswegen sind aber auch manche sachen etwas komplizierter, bzw. nicht so einsichtig, wenn man nicht täglich damit arbeiten (Copy-Ctor und ähnliche geschichten).
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.
Operator-Überladung ist zwar ganz witzig, aber es macht für das Design eines Programms eigentlich keinen unterschied.
Einer der größten Vorteile von C++ gegenüber den meisten OO-Sprachen ist aber die automatische Destruktion von Objekten. Damit (RAII) kann man sich das ganze Garbage-Collection-Zeug sparen, man kann das gleiche Prinzip für jede Art von Resourcen-Belegung anwenden und tut sich leichter bei der Ausnahmebehandlung. Hier ist Delphi klar in Nachteil, weil es eben auch keine Garbage-Collection hat und man dadurch ziehmlich viel mit try-catch-finally-Klauseln arbeiten muss.
Außerdem bleiben dann natürlich noch die Templates. Delphi hat da nichts Vergleichbares zu bieten.
Dafür hat Delphi aber in der Handhabbarkeit einige Vorteile. imho ist der Code wesentlich leichter zu lesen. Ich arbeite täglich mit c++ und so gut wie nie mit Delphi, kann aber den Code in etwa gleich gut lesen. Pascal-Code ist einfach übersichtlicher. Von der Geschwindigkeit sind Delphi-Progs in der Praxis (außer bei hoch-Performance-Anwendungen) wohl gleichwertig, mir ist aber noch nie ein C++-Compiler untergekommen der nur annäherungsweise so schnell compiliert wie Delphi.
In C++ hat man natürlich sehr viel mehr Spielraum für sein Programmdesign, weil mehr Sprachparadigmen unterstützt werden. Andrerseits hat das auch zur folge, dass man nur einen geringen Teil der Sprache wirklich nutzt (und jeder Programmierer nen anderen) und man schon einiges an Lehrzeit investieren muss, bevor man richtig produktiv mit arbeiten kann. In Delphi wird man viel schneller produktiv, irgendwann fühlt man sich aber vielleicht eingeengt. C++ gleicht insofern eher einer natürlichen gewachsenen Sprache mit vielen eleganten und auch unschönen Möglichkeiten, etwas auszudrücken, Delphi ist halt mehr einfach gestrickt.
-
Sehr schöne Zusammenfassung.
Kleines Detail: In Delphi sind alle Klassen von TObject abgeleitet,
auch wenn man es nicht explizit hinschreibt.TMyClass = class //.. end;ist gleichwertig mit
TMyClass = class(TObject) //.. end;
-
Original erstellt von Taurin:
**
Kleines Detail: In Delphi sind alle Klassen von TObject abgeleitet,
auch wenn man es nicht explizit hinschreibt.
[/code]**Inwiefern stellt das eigentlich, wie hier von einigen vertreten, einen Nachteil dar?
-
Original erstellt von Bashar:
Inwiefern stellt das eigentlich, wie hier von einigen vertreten, einen Nachteil dar?IMHO ist das insofern ein nachteil da ich keinen vorteil sehe.
was ist der vorteil von so einer basisklasse.
-
Original erstellt von Shade Of Mine:
**IMHO ist das insofern ein nachteil da ich keinen vorteil sehe.was ist der vorteil von so einer basisklasse.**
...und ich sehe es als Nachteil von C++ an, dass der Dereferenzierungsoperator * und nicht § ist. Grund : Ich sehe keinen Vorteil von * gegenüber §.
EDIT : *SCNR*
[ Dieser Beitrag wurde am 07.01.2003 um 15:52 Uhr von Gregor editiert. ]
-
Original erstellt von Gregor:
...und ich sehe es als Nachteil von C++ an, dass der Dereferenzierungsoperator * und nicht § ist. Grund : Ich sehe keinen Vorteil von * gegenüber §.
EINE basisklasse bedeutet das fehlen von mehrfachvererbung - es sei denn man wuerde automatisch virtual erben... aber das waere wohl auch nicht ideal.
sag mal was der vorteil an einer basisklasse ist.
-
Original erstellt von Shade Of Mine:
EINE basisklasse bedeutet das fehlen von mehrfachvererbungNö, siehe z.b. CLOS
**
- es sei denn man wuerde automatisch virtual erben... aber das waere wohl auch nicht ideal.**Bitte ausführlicher.
**
sag mal was der vorteil an einer basisklasse ist.**Die Behauptung, es wäre ein Nachteil, kam zuerst.
-
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.