warum C++ statt Delphi?

[pixfreak]

Hallo zusammen,

C++ ist um ein vieles mächtiger als Delphi. Allein die Template Möglichkeiten gehen bei weitem über die der Generics von Delphi hinaus.

Oder die Möglichkeit der Mehrfachvererbung: Ok, man muss schon aufpassen, was man da wie vererbt, das kann sehr schnell unübersichtlich und fehleranfällig werden, lässt einem aber doch weite Freiheiten. Die Interface sind da nur ein fadenscheiniger Ersatz.

Mit Boost bzw. jetzt dem neuen Standard kann man viele schöne Sachen machen, Multithreading z.B. ist reltiv schnell und sicher umgesetzt.

Ja und da ist noch die Sache, dass ich fast jede Klasse auch lokal instanziieren kann und nicht immer mit new einen neuen Speicherplatz dynamisch anfordern muss. In Delphi gibt es da ganz schnell diese häßlichen try..finaly Verschachtelungen, wenn ich mal etwas mehr in einer Methode brauche, ok, etwas am Design verändert, kann ich das vielleicht auch vermeiden.

Ich persönlich mag C++ sehr gerne und kann damit auch recht gut um, es bedarf allerdings eine lange Lernphase, aber wenn man es drauf hat, dann kann man recht dolle Sachen damit machen.

Persönlich fehlt mir in C++ aber die with-Anweisung, da hat Delphi was voraus

Ich finde, das vergleichen der Sprachen ist aber nur eine seite der Medallie. Zum proggen brauche ich auch noch einen Compiler und am besten eine ordentliche IDE. Und da geht es schon los.

Wenn ich das richtig verfolgt habe, sind die neuen C++ Features nur im 64 Bit Compiler verfügar, man belehre mich, wenn ich mich irren sollte. Für 32 Bit werkelt immer noch der alte. Die Produktivität ist mit dem C++ Builder nicht mit Delphi zu vergleichen, ein Hauptgrund warum ich als One-man-Tastaturhämmerer auf Delphi setze, wegen z.B.

• keine Refaktorings, außer Umbenennen, und das nur sehr oberflächlich
• keine Klassenvervollständigung ala Strg-shift-C, man muss immer in zwei Dateien, Header und Code, die Funktionen einfügen und bearbeiten (ok, mit UML gehts auch so, der Klassenbrowser regt mich in den akuellen Versionen nur auf)
• VCL wird halt irgendwie mit rein operiert, VCL Klassen müssen dynamisch angelegt werden, statisch geht nicht
• der Experte für vorcompilierte Header ist tricky, man muss schon selbst Hand anlegen, damit ordentliche precomiled Headers heraus kommen, die auch was bringen in Bezug auf Compiliergeschwindigkeit. Und da kommen z.B. die DevExpress Compos, die haben in einem Header Daten stehen und die zerschießen den precomiled Header so, dass er nicht verwendet werden kann. Ich hab das schon mehrmals denen geschrieben, ist aber in jeder Version wieder drinne... (Ich habs dann mal rausoperiert...)
• der Delphi Compiler ist um Welten schneller, ok für den Builder gibt es TwineCompile, da sieht man mal, was ginge, aber Delphi bleibt schneller (single-pass)
• Code-completion funktioniert nur mit einem ordentlichen precomiled Header und auf einem schnellen Rechner ordentlich, sonst passiert es schon mal, dass man über eine Sekunde wartet, bis die Code completion angezeigt wird, und ist sie einmal angestossen muss man auch warten und kann nicht weitertippen

Also, der Emba Compiler (ich rede jetzt mal nur vom 32er) ist wie schon gesagt, meilenweit hinter den aktuellen Compilern zurück. Aber es gibt noch ein Problem: Welches Tool nimmt man für die Oberflächenprogrammierung? Ok, QT fällt mir gerade ein, VCL braucht die Builder IDE und die ist grottig, MFC ist doch eh fast WinAPI, ja und dann?

Also meine Meinung: Für "Backboxen" würde ich C++ mit einem vernünftigen Compiler nehmen, kommt eine GUI dazu, dann entweder in Schichten mit verschiedenen Systemem arbeiten oder eben auf das Brot- und Wassertool Delphi ausweichen. (Um .net habe ich bis jetzt einen Bogen gemacht und Java mag ich persönlich nicht so...)

So, nun denn, frohe Weihnachten!


Gruß Pixfreak

[Bernhard Geyer]

Zitat von pixfreak:

C++ ist um ein vieles mächtiger als Delphi. Allein die Template Möglichkeiten gehen bei weitem über die der Generics von Delphi hinaus.

Vielfaches halte ich übertrieben. Es ist in einzelnen Bereichen Mächtiger.

Zitat von pixfreak:

Oder die Möglichkeit der Mehrfachvererbung: Ok, man muss schon aufpassen, was man da wie vererbt, das kann sehr schnell unübersichtlich und fehleranfällig werden, lässt einem aber doch weite Freiheiten. Die Interface sind da nur ein fadenscheiniger Ersatz.

Voll Kontra. Ich kenn nur C++ die Mehrfachvererbung kann und das auch nur weil man nicht fähig war mit Interfaces einen vernünftige Implementierung hin zu bekommen.
Mehrfachvererbung verursacht bei weiten mehr Probleme als es löst. Interfaces ist ein Sprachkonstrukt ohne das viele Realisierungen nicht so elegant zu realisieren wären.

Zitat von pixfreak:

Mit Boost bzw. jetzt dem neuen Standard kann man viele schöne Sachen machen, Multithreading z.B. ist reltiv schnell und sicher umgesetzt.

Das fehlt bei Delphi natürlich (wie so viele Spezialbibliotheken die man nur für C/C++ zur verfügung stellt).

Zitat von pixfreak:

Ja und da ist noch die Sache, dass ich fast jede Klasse auch lokal instanziieren kann und nicht immer mit new einen neuen Speicherplatz dynamisch anfordern muss.

Ich vermiss das nicht

Zitat von pixfreak:

In Delphi gibt es da ganz schnell diese häßlichen try..finaly Verschachtelungen, wenn ich mal etwas mehr in einer Methode brauche, ok, etwas am Design verändert, kann ich das vielleicht auch vermeiden.

Ohne GC (wie bei Java) muss man halt die ganzen Variablen etwas früher en Block anlegen. Dann kommt man mit 1-2 try-finaly-Ebenen aus.

Zitat von pixfreak:

Ich persönlich mag C++ sehr gerne und kann damit auch recht gut um, ...

Ich bin froh das ich es im Berufsleben nur relativ kurz benötigt hatte und dort dann nach Delphi umstellen konnte. Der Produktiviätsgewinn gegenüber MFC/VisualC++ war gewaltig.

Zitat von pixfreak:

Persönlich fehlt mir in C++ aber die with-Anweisung, da hat Delphi was voraus

Die With-Anweisung fliegt bei uns immer raus wenn man sie trifft. Die ungewollten Fehler damit sind zu zeitaufwendig zu finden. Wenn man doch wie in VB den Punkt nicht eingespart hätte ....

Zitat von pixfreak:

Also meine Meinung: Für "Backboxen" würde ich C++ mit einem vernünftigen Compiler nehmen, kommt eine GUI dazu, dann entweder in Schichten mit verschiedenen Systemem arbeiten oder eben auf das Brot- und Wassertool Delphi ausweichen. (Um .net habe ich bis jetzt einen Bogen gemacht und Java mag ich persönlich nicht so...)

Unnötigerweise mehre IDE's und Sprachen einzusetzen kann schnell zum Scheitern eines Projektes führen. Wir hatten vor ca. 12 Jahren ein neues Projekt aufgesetzt. Zuerst hatten wir alle uns schön in .NET mit VS eingearbeitet und hatten schon soweit uns alle damit anzufreunden und es als die sinnvolle Lösung angesehen haben (Waren gemischt Delphi, MFC/VS-Entwickler und eine paar "Hardcore" C-Entwickler die primär auf Embedded-Systemen gearbeitet hatten). Jedoch gab's eine paar "superschlaue" Externe (die auch noch was zu sagen hatten) die meinten wir müssten das anders machen und auf existierende Lösungen aufsetzen wie ein auf FTP basierendes Messaging-System (Welchen Vorteil FTP hier hatte ist mir heute noch nicht klar). Es wurde dann festgelegt den einen Teil mit C umzusetzen ist(ist ja schön portierbar falls man irgendwann mal eine Port nach Linux benötigt), die Mittleware mit C++ (letztendlich ATL und MFC schön gemischt mit maximaler komplexität) und Client war dann noch offen ob .NET oder Delphi. Da wir schon einen Großteil des Vorteils einer einheitlichen Umgebung aufgegeben hatten sind wir bei Delphi geblieben.
Bei der ersten Integrationsphase hat sich dann gezeigt wo die Probleme lagen und ich hätte jede Wette gewonnen da es mal wieder typisch vagabuntierende (String-)Zeiger auf C++-Seite waren. Hab mir dann relativ schnell einen anderen Job gesucht da es klar war das diese Lösung mit Volldampf an die Wand fährt.