C++ / Delphi
-
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.
-
Dann will ich mal die Diskussion wieder anheizen *g*. Da ich sowohl mit Delphi als auch mit C++ mehrere Jahre meine Brötchen verdient habe, bilde ich mir ein, dass ich meinen Senf dazugeben kann.
Die Äußerungen von kartoffelsack gefallen mir prinzipiell ganz gut, auch wenn ich in einzelnen Punkten nicht ganz zustimmen kann.
Was meinst Du mit der „automatische Destruktion von Objekten“? Meinst Du damit, dass am Ende des Scopes ein Objekt automatisch freigegeben wird, wenn dieses nicht dynamisch angefordert wurde oder gibt es in C++ etwas, was mir all die Jahre verborgen geblieben ist?
In Delphi kann man sich das try finally sparen, wenn man sich die Mühe macht mit Interfaces zu arbeiten. Man muss einfach im Einzelfall entscheiden, ob sich der Aufwand lohnt.
Weiterhin gibt es in Object Pascal nicht nur „class“ sondern auch „object“. Das ist ein Überbleibsel aus Turbo Pascal 5.5-Zeiten. Derartige Klasen verhalten sich ähnlich wie C++-Klassen. Man kann also nicht nur dynamisch eine Instanz erzeugen, sondern auch eine, die autom. am Anfang der Methode erzeugt und am Schluss wieder freigegeben wird. „object“ wird aber normalerweise von Delphi-Programmierern nicht verwendet.
Bei Delphi für .NET ist dann auch zwangsweise Garbage Collection mit dabei.Es stimmt, dass Delphi zu den Templates nichts vergleichbares hat. Ich persönlich mag Templates aber nicht besonders.
Template-Code lässt sich IMHO sehr schwer lesen.
Durch Templatecode zu debuggen ist ein Drama. Ich weiß meistens nicht einmal in welcher Klasse ich mich gerade befinde. Wenn man bei Parametern mit STL-Klassen arbeitet muss man sich immer erst durch etliche Zeilen STL-Code quälen, bevor man in der Methode landet, die man eigentlich debuggen will.
Und was ich am meisten an den Templates hasse, ist dass sie die Übersetzungszeit endgültig in den Keller abgehen lassen.
Die Typsicherheit von Templates bekomme ich bei Delphi dadurch, dass ich das von Hand mache, was bei Templates vom Compiler erledigt wird. Ich kopiere den ganzen Code einer speziell geschriebenen Klasse und lasse durch suchen/ersetzen den Typ einsetzen. Das kostet mich zwar etwas Zeit beim Tippen, die bekomme ich aber wieder um ein vielfaches zurück, dadurch, dass sich der Code besser lesen, debuggen und viel schneller übersetzen lässt.Es wurde hier geäußert, dass sich C++ bei großen Projekten besser eignen würde als Delphi. Ich bin genau anderer Meinung. C++ hat gegenüber ObjectPascal etliche Vorteile, aber unter dem Strich steht bei mir ObjectPascal klar vor C++. Mit Delphi lassen sich große Projekte viel schneller entwickeln als z.B. mit dem C++Builder.
Bei großen Projekten arbeiten immer etliche Entwickler zusammen. Somit treffen auch mehrere Programmierstile aufeinander. Da C++ viel mehr Freiraum lässt, wie man es programmiert, steigt das Risiko, dass der eine Code produziert in dem sich der andere nur schwer zurecht findet.
Ich habe momentan das Problem, dass ich jemanden einarbeiten muss, der aus der VB-Ecke kommt. In unserem Projekt wird aber fast alles verwendet, was C++ so hergibt. Es wäre sicherlich deutlich leichter für den Neuen sich in ein entspr. Delphi-Projekt einzuarbeiten.
Bei C++-Compilern darf man nach Fehlern suchen, die ein Delphi-Programmierer nie zu sehen bekommt. Einer meiner Lieblinge ist „unresolved external“. Bei Delphi gibt es zwar auch eine Fehlermeldung, die in eine ähnliche Kerbe schlägt. Aber selbst die haben bestimmt die meisten Delphiprogrammierer noch nie zu sehen bekommen.
Was aber am meisten Zeit kostet ist der langsame C++-Compiler. Wenn ich unser Projekt komplett übersetzen lassen muss, dann kann ich zwei Stunden (P4 mit 1,5GHz) lang etwas anderes tun. Ich habe eine Unit (C++Builder) die sage und schreibe alleine über drei Minuten zum übersetzen braucht. Mal schnell etwas ausprobieren kann man da komplett vergessen. Ich habe etliche Stunden/Tage nur damit verbracht, mir zu überlegen, wie ich den Code umstrukturiere, damit die Übersetzungszeiten besser werden. Zu allem Überfluss kommen mit dem VisiBroker (CORBA) noch Headerdateien dazu, die ich nicht in die vorcompilierten Headerdateien mit aufnehmen kann, da diese sonst gar nicht erzeugt werden.
Als ich vor etlichen Jahren ein ähnlich großes Projekt mit Delphi umgesetzt habe, hat selbst das komplette erzeugen nur knapp über eine Minute (Pentium II 350 MHz) gedauert.Es macht keinen Spaß ständig auf den C++-Compiler warten zu müssen.
Die Diskussionen über Schleifen, begin/end, oder über den Sinn/Unsinn dass alle Klassen von TObject abgeleitet sein müssen, ist in meinem Augen Kleinkram, der nicht wirklich Einfluss darauf haben sollte, für welche Sprache/Entwicklungsumgebung man sich entscheidet.
-
Was meinst Du mit der ?automatische Destruktion von Objekten?? Meinst Du damit, dass am Ende des Scopes ein Objekt automatisch freigegeben wird, wenn dieses nicht dynamisch angefordert wurde oder gibt es in C++ etwas, was mir all die Jahre verborgen geblieben ist?
Damit mein ich, dass man alles, was unbedingt getan werden muss in einen Destruktor reinpackt und damit sicherstellt, dass es ausgeführt wird - bei einer Exception genauso wie im normalen Programmfluss.
Anwendungsbeispiel: SmartPointer. Wenn die letzte Referenz eines Pointers die Gültigkeit verliert, wird der Speicher freigegeben.
Dieses Prizip (Resource Aquiration is initialisation = RAII) kann man aber auf alle Arten von Resourcen Anwenden, wodurch es einer Garbage-Collection überlegen ist.Der C++Builder ist übrigens ganz besonders übel in sachen Compile-Zeit. Bei anderen Compilern is das nicht so extrem. Leider haben die andere Nachteile
