Firmenfrage zu C++ vs. Delphi

[Money Making Machinist]

Hi,

ich hätte da mal einen Frage: Kann es sein, das Unternehmen immernoch stark auf C++ bei der Softwareentwicklung setzen bzw. Delphi eher selten einsetzen?

Ich frage mich halt grad, warum C++, bei dem es eigentlich doch recht aufwändig ist eine anständige Oberfläche zu gestalten (von aufwendigen Konsolenmenüs gar nicht zu reden). Und in Delphi geht das doch mit wenigen Klicks, wo man ich glaub für MFC oder cross-platform toolkits doch schon einige Zeilen schreiben muss, um gleiches zu erreichen. Woran liegt das eigentlich?

*Anmerkung:

Das ist KEIN Aufruf zu einem Flamewar was besser wäre, es geht nur darum warum Firmen mehr C++ und weniger Delphi benutzen

[Bubble]

Die Gründe sind vielfältig, einen bestimmten Grund gibt es IMO nicht. Hier einmal mögliche Gründe, die mir spontan einfallen:

Es gibt viel C++ Code, den niemand ersetzen will, aber weiter genutzt wird. Es haben relativ viele Entwickler mit C++ Erfahrung. Man kann mit C/C++ bei Bedarf auch hardwarenah Programmieren, was nicht in allen Programmiersprachen gleichermaßen möglich ist. Mit Visual C++ kann man immer den aktuellen PSDK nutzen und hat somit Zugriff auf alle aktuellen Features vom Windows SDK. C++ Compiler gibt es für viele Systeme, so dass Code ohne Betriebssystemabhängigkeiten portabel (nur erneute Kompilierung erforderlich) gestaltet werden kann.

[Guybrush Threepwood]

Außerdem ist Windows teilweise mit C geschrieben, das heißt alle Windows APIs basieren auf C. Somit ist es sehr viel einfacher direkt mit C/C++ darauf zuzugreifen als mit anderen Sprachen. Damit hat man mehr Möglichkeiten, auch wenn es oft umständlicher bzw. schwieriger ist.

[Pointerman]

Moin!

Also wenn die komfortable Oberflächengestalltung Dein einziges Problem ist:

Borland bietet den C++ Builder an. Gleiche IDE wie Delphi. Erleichtert einem Delphianer(wie mir) den Umstieg erheblich. Außerdem bietet der C++ Builder auch die gleichem Klassenbibliotheken wie Delphi (VCL und CLX).

[Bubble]

Richtig, aber die Frage, die ich mit stelle, ist ob diese Klassenbibliotheken eine Zukunft haben. Ich vermute bei der Entwicklung von GUIs unter Windows und RAD im Allgemeinen geht es zukünftig deutlich in Richtung .NET. Und wer für ein GUI-Programm wirklich alle Features von Windows ausnutzen will, wird sein Programm oder einige Teile davon vermutlich eh direkt gegen das Win32 API programmieren (müssen).

[Money Making Machinist]

Die Frage is doch, braucht man wirklich so oft wirklich alle Funktionen von Windows? Sicher manchmal schon, aber wie oft kommt das schon vor?!

[Bubble]

Sicher nicht. Deswegen wollte ich auch einmal die Frage in den Raum stellen, auf welche Klassenbibliothek (.NET Bibliotheken, MFC, VCL, QT, usw.) man setzen sollte, auch in Hinblick auf eine zukünftige Weiterentwicklung durch den Hersteller.

Mir ist natürlich klar, dass es keine Antwort für alle Projekte gibt, aber es gibt sicher Unterschiede, wenn auch nur "gefühlte", was die Zukunfssicherheit angeht.

[geloescht_JesterDay]

Außerdem ist Windows teilweise mit C geschrieben, das heißt alle Windows APIs basieren auf C.

Das ist richtig, aber das heisst ja nur, dass der aufruf nach C-Syntax gemacht werden muss (PChar anstelle von String z.B.). Ansonsten ist es kein Unterschied, da der API-Code ja nur ausgeführt, nicht ins Programm kopiert wird.

Es ist kein Problem Delphi-erstellte DLLs unter C/C++ zu nutzen und umgekehrt auch nicht. APIs sind nichts anderes als fertiger code, der so zur Verfügung gestellt wird.

Mehr möglichkeiten hat man deshalb mit C nicht, für die meisten APIs gibt es sogar Wrapper um sie einfach im Delphi-Stil aufzurufen.

Ein Vorteil von C ist natürlich die plattformunabhängigkeit, ABER: Wenn von Win-APIs geredet wird, ist es nicht mehr plattformunabhängig. Auch die MFC ist alles andere als das. C allein macht ein Programm nicht plattformunabhängig, C++ noch weniger.

IMHO sind es vorallem Vorurteile, die für bzw. gegen Programmiersprachen sprechen. Wenn du z.B. von Windowsprogrammierung redest, hat hardwarenahe Programmierung da nichts zu suchen. Dafür sorgt allein schon der HAL von Windows. Es wäre auch mit Delphi möglich, ein OS zu programmieren (link dazu hab ich nicht mehr, leider). Der Geschw.-Vorteil von C ist auch minimal und kommt vorallem daher, dass es C-Compiler von vielen Anbietern gibt, Delphi kommt nur von Borland. So kann jeder seinen Compiler optimieren, irgendwann ziehen andere nach und machen woanders nochwas besser...

Es kommt wohl wirklich nur auf die Vorlieben des Entscheiders an.

Ein weiteres Plus für C (C, ohne ++) ist die weite Verbreitung und die Standardisierung der Sprache. Fast überall wo Code läuft (Hardware) wird C verwendet. C ist für viele einfach soz. ein Synonym für eine (gute) Programmiersprache. Ob das stimmt oder nicht soll jeder für sich entscheiden.

Ach ja, C++ wird nichtmal vom Erfinder von C als gut empfunden

[perdian]

Ein Vorteil von C ist natürlich die plattformunabhängigkeit

:beagolisc Bitte? C und Plattformunabhängigkeit? Das wäre mal was neues.

Die Sprache C ist plattformunabhängig - das war's dann aber auch schon. Ein int kann ja schonmal je nach Plattform (16bit, 32bit, 64bit) einen unterschiedlichen Wertebereich annehmen - damit ist die Plattformunabhängigkeit schon wieder weg.

Klaro, ein

int main() {

  cout << "Hello World" << endl;

}

läuft auf allen Plattformen, aber wenn die Programme komplexer werden, ist es damit auch schon genug. Davon, wie Prozesse und Threads implementiert sind spricht da noch niemand

Zurück zur Ausgangsfrage: Letzten Endes ist da viel historisch gewachsen. Delphi ist was das Handling angeht sicherlich in vielen Bereichen C gegenüber deutlich überlegen - genauso allerdings ist C dafür in anderen Bereichen, wie Hardware, überlegen. Es gibt also kein objektives besser oder schlechter.

Deshalb gilt bei vielen Entwicklern der Grundsatz "In C kenne ich mich aus, wieso also eine neue Sprache lernen und verwenden?". Und wenn dir als Chef dein Mitarbeiter sagt "In C brauche ich für die Umsetzung des Projektes zwei Tage, mit Delphi mindestens eine Woche", dann ist klar, wer das Rennen gewinnt.

Das ist natürlich nur ein Ausschnit, es gibt noch viele andere Gründe die da mit reinspielen.

Trotzdem denke ich ist C(++) im Moment was Oberflächenentwicklung angeht deutlich auf dem absteigenden Ast. .NET wird da vielleicht wieder einiges gutmachen können, aber es gibt inzwischen manch andere Sprachen, mit denen du viel leichter und sauberer auch komplexe GUIs programmieren kannst. Und wer schonmal in Java mit Swing oder SWT gearbeitet hat wird es nie wieder verstehen, wieso sich manch einer noch freiwillig mit manuellen Windows API aufrufen rumschlägt.

[Guybrush Threepwood]

Das ist richtig, aber das heisst ja nur, dass der aufruf nach C-Syntax gemacht werden muss (PChar anstelle von String z.B.). Ansonsten ist es kein Unterschied, da der API-Code ja nur ausgeführt, nicht ins Programm kopiert wird.

Das ist sicherlich richtig, aber wenn du den 2ten Satz mitzitiert hättest dann hätte es wieder Sinn ergeben

Es ist nunmal mit C oder C++ sehr viel einfach auf alle APIs von Windows oder DirectX oder sonst was zuzugreifne weil sie auf der selben Sprache basieren.

[Bubble]

Und wer schonmal in Java mit Swing oder SWT gearbeitet hat wird es nie wieder verstehen, wieso sich manch einer noch freiwillig mit manuellen Windows API aufrufen rumschlägt.

Hier muss ich protestieren. Swing ist vom Aufbau her sicherlich eine gute Idee, das Resultat ist, meiner Ansicht nach, im Vergleich zu GUI-Bibliotheken mit ähnlichen Intentionen jedoch zu langsam. Der langsame Bildaufbau, bei kleinen Tools noch ertragbar, von großen Swing Programmen (z.B. Forte) zerrt aufgrund des mangelnden Ansprechverhaltens so enorm an meinen Nerven, dass ich derzeit kein großes Swing basierendes Programm mehr freiwillig nutze und Forte ebenfalls deinstalliert habe.

Ich denke, es gibt schon einen Grund, dass beispielsweise Eclipse nicht Swing als GUI-Bibliothek verwendet. Im Vergleich zu Swing Anwendungen haben .NET GUI Anwendungen (auch wenn sie selbst gezeichnete Controls verwenden und nicht auf Windows-Controls zurückgreifen) ein meiner Erfahrung nach deutlich besseres Ansprechverhalten. Und genau das ist mein Hauptproblem mit Swing: Es ist nicht schnell genug. Da hilft auch ein gutes Design nicht drüber hinweg, wenn der Benutzer später leidet.

Der Vergleich mit der Windows API (und genauso anderen C basierten GUI Bibliotheken, z.B. unter Unix oder die vom Amiga) ist jedoch nicht ganz gerecht, da sie langsam gewachsen ist und aus Kompatibilitätsgründen bis heute eine Menge mitschleppt und nichts Grundlegendes umgestellt wurde. Swing hingegen war eine objektorientierte Neuentwicklung. Ich vermute, dass sich der GUI RAD Bereich unter Windows mehr in Richtung .NET begibt, sicherlich auch aufgrund der gut gelungenen Programmiersprache C#.

Für Java mit Swing spricht weiterhin die Plattformunabhängigkeit, die andere Sprachen und Bibliotheken momentan in dieser Weise nicht bieten. Auch wenn in der Praxis für eine Anwendung meist eine bestimmte Zielplattform vorgegeben ist, kann man den Java-Code problemlos wieder verwenden, auch wenn sich im nächsten Projekt die Vorgabe ändert. C ist zwar prinzipiell auch portabel (erneute Kompilierung nötig, es darf auf keine von Plattformen abhängigen Bibliotheken zurückgegriffen werden, man darf keine festen Annahmen über Datentypen, Wertebereiche, usw. machen), in der Praxis ist es jedoch deutlich schwieriger.

[geloescht_JesterDay]

Der langsame Bildaufbau, bei kleinen Tools noch ertragbar, von großen Swing Programmen (z.B. Forte) zerrt aufgrund des mangelnden Ansprechverhaltens so enorm an meinen Nerven, dass ich derzeit kein großes Swing basierendes Programm mehr freiwillig nutze und Forte ebenfalls deinstalliert habe.

Habe ich auch immer so gesehen, das letzte Java Projekt, dass ich installiert hatte war... weiss den Namen gar nicht mehr... irgend ein (mittlerweile) OpenSource 3DRenderer. Aber sieh dir z.B. mal Azureus an, ein Bittorrent Client.

Den hab ich genutzt und war voll zufrieden, auch was die Geschw. angeht nur am dann später zu Erfahren: Azureus ist ein Java Programm. Es unterscheidet sich nicht (weder aussehen noch Geschw.) von einem nativen Windows Programm.

Man kann in Java wohl schon gute Programme schreiben, nur ist es wohl häufig so, dass es nicht gemacht wird.

Zur Plattformunabhängigkeit von C. Ich meinte damit nicht binär kompatibel. Aber selbst wenn es eine gewisse Anpassung braucht, ist der Aufwand doch vergleichbar gering. Apache gibt es z.B. für so gut wie jedes System. Das größte Problem ist aber auch hier (also bei C, nicht dem Apache) das GUI. Auch wenn es da schon ein paar plattformübergreifende Ansätze gibt.

[geloescht_JesterDay]

Das ist sicherlich richtig, aber wenn du den 2ten Satz mitzitiert hättest dann hätte es wieder Sinn ergeben

Es ist nunmal mit C oder C++ sehr viel einfach auf alle APIs von Windows oder DirectX oder sonst was zuzugreifne weil sie auf der selben Sprache basieren.

Ich sehe den aufwand von Delphi aus einen API-Call zu machen nicht höher als in C/C++.

TForm1 = Class(TForm)

private

  someFunction(aString: PChar); external 'someDll.dll';

public


end;



Ob ich someFunction('String'); in Delphi schreibe oder

someFunction(PChar('String')); sind nur ein paar Zeichen mehr.

Und gerade für DirectX gibt es mit DelphiX einen Wrapper um die komplette API ohne die Umwandlung aufrufen zu können (Was nicht heisst, es geht nicht ohne).

Was richtig ist ist, dass es für Leute die nur Delphi kennen und von C-Syntax keine Ahnung haben schwerer ist. Das liegt aber dann nicht an Delphi.

EDIT:

Ich denke wir kommen damit aber vom Thema ab... also Fakt ist, dass ich denke es sind nur die pers. Vorlieben und nicht sprachbedingte Unterschiede die zu sowas führen. (auch zu solchen abschweifenden Diskussionen )

[Bubble]

Azureus ist ein Java Programm. Es unterscheidet sich nicht (weder aussehen noch Geschw.) von einem nativen Windows Programm.

Benutzt es Swing? Hat es eine sehr aufwendige Benutzeroberfläche, oder ist es eher einfach aufgebaut?

Zur Plattformunabhängigkeit von C. Ich meinte damit nicht binär kompatibel. Aber selbst wenn es eine gewisse Anpassung braucht, ist der Aufwand doch vergleichbar gering. Apache gibt es z.B. für so gut wie jedes System. Das größte Problem ist aber auch hier (also bei C, nicht dem Apache) das GUI. Auch wenn es da schon ein paar plattformübergreifende Ansätze gibt.

Also Apache verwendet mit Sicherheit ein geeignetes Design mit einer Abstraktionsebene, die genau festgelegte Schnittstellen hat. Unterhalb dieser Ebene werden sicherlich alle betriebssystemspezifischen Anteile jeweils ausgetauscht. Die Unterschiede zwischen den einzelnen Versionen dürften somit erheblich sein, von einer einfachen Anpassung würde ich daher nicht sprechen wollen, das Design muss dafür von Anfang an geeignet sein.

Ich sehe den Aufwand von Delphi aus einen API-Call zu machen nicht höher als in C/C++.

Es ist schon etwas aufwendiger, denn Du musst das, was in den C-Header-Dateien steht, in Delphi umsetzen. Wenn Du C verwendest, benutzt Du einfach die (beim PSDK, DirectX, usw.) mitgelieferten Header-Dateien. Und wenn von den APIs eine neue Version erscheint, musst Du nicht selbst nacharbeiten, um sie nutzen zu können.

[Money Making Machinist]

Deshalb gilt bei vielen Entwicklern der Grundsatz "In C kenne ich mich aus, wieso also eine neue Sprache lernen und verwenden?". Und wenn dir als Chef dein Mitarbeiter sagt "In C brauche ich für die Umsetzung des Projektes zwei Tage, mit Delphi mindestens eine Woche", dann ist klar, wer das Rennen gewinnt.

Ernsthaft? Ich hab bei Delphi immer so das Gefühl es geht oft, zwar nicht immer klar, aber doch immer etwas schneller als in C.

Ich schreib das aus meinen Erfahrungen, kann ja nichts dafür wenn ich noch nie ein "wirklich" großes Projekt (100k Zeilen) geschrieben hab.

[perdian]

Swing ist vom Aufbau her sicherlich eine gute Idee, das Resultat ist, meiner Ansicht nach, im Vergleich zu GUI-Bibliotheken mit ähnlichen Intentionen jedoch zu langsam.

Da ist es wieder - das Vorurteil Java sei langsam

Es kommt natürlich darauf an, unter welchen Bedingungen, du welche Swing-Programme betrachtest. Ich habe selber schon mit großen Swing-Programmen gearbeitet und auch selbst schon komplexe GUIs geschrieben, die sich Geschwindigkeitsmäßig nicht hinter nativen Anwendungen verstecken mussten. Gerade mit Java 5.0 hat sich da auch wieder einiges getan. Richtig ist natürlich, dass es schon mindestens ein PIII sein sollte, sonst macht das Arbeiten damit keinen Spaß.

Auch hier gilt eigentlich: Es kommt darauf an, wie du die Programme schreibst. Auch mit Swing kann man einiges an Fehlern machen (Panels schachteln bis zum Erbrechen und andere Dinge), die dann an der Performance ziehen - aber das hat nichts mit dem Konzept Swing an sich zu tun. Versauen kann ich in jeder Sprache

Für Java mit Swing spricht weiterhin die Plattformunabhängigkeit, die andere Sprachen und Bibliotheken momentan in dieser Weise nicht bieten.

Eben, und ich denke genau da wird sich in Zukunft noch einiges tun. Ich habe in der Vergangenheit ein und dasselbe Swing-Programm auf drei verschiedenen Architekturen (Win, Linux, Mac) laufen gehabt - mit minimalsten Anpassungen. Sowas ist für heterogen ausgestattete Firmen schon ein massiver Pluspunkt.

[geloescht_JesterDay]

Benutzt es Swing? Hat es eine sehr aufwendige Benutzeroberfläche, oder ist es eher einfach aufgebaut?

Keine Ahnung ob es Swing nutzt.

Hier einige Screenshots (entscheide selbst, ob du das aufwendig findest oder nicht):

http://azureus.sourceforge.net/screenshots_v2.php

und hier die HP:

http://azureus.sourceforge.net/

[perdian]

Keine Ahnung ob es Swing nutzt.

Hab gerade mal die Sourcen gezogen: Genutzt wird SWT.

[Bubble]

Da ist es wieder - das Vorurteil Java sei langsam

Ich habe nicht gesagt Java sei langsam, ich habe gesagt Swing ist im Hinblick auf das Antwortverhalten subjektiv langsamer, als von anderen nicht Swing Programmen gewohnt.

Die Java JIT Runtime selbst ist schnell, da kann man nichts gegen sagen. Andere Java GUI-Toolkits sind ja auch angenehmer. Mit der GUI von Eclipse habe ich beispielsweise keine Probleme.

Richtig ist natürlich, dass es schon mindestens ein PIII sein sollte, sonst macht das Arbeiten damit keinen Spaß.

Ist doch eigentlich Wahnsinn, einen P3 zu verlangen.

Aber letztlich, die Entscheidung vor eine Programmiersprache und die APIs sollte vom Ziel und dein eigenen Präferenzen abhängen. Vieles hat seine Stärken und vieles hat seine Schwächen. Wer Delphi mag, soll es gerne benutzen, auch wenn es z.B. für mich augenblicklich nicht in Frage käme.