XE6: Hauptfenster startet nicht

asc

Burkhi schrieb:

Da ist C/C++ m.E. teilweise noch viel unleserlicher, man schaue sich z.B. nur mal die Quelltexte der std templates an.

Ich finde C++/Java und C# jedenfalls angenehmer vom Lesen her, und das obwohl ich mit C++ erst nach Pascal (und zuvor GFA-Basic) angefangen habe, und anfangs (wenn auch nicht allzu lange) die Sprache auch gut fand. Mehr brauche ich dazu auch nicht zu sagen - im Gegensatz zu Beispielsweise Java, bei dem ich einen WG-Mitbewohner einmal bei der Fehlersuche geholfen hatte bevor ich selbige Sprache erlernt hatte, habe ich Schwierigkeiten mit dem Lesen von Delphi-Code.

Mehr ist hierzu aus meiner Sicht nicht zu sagen. Delphi finde ich genauso unleserlich wie Visual Basic. C++ ist sicherlich nicht das Optimum von Lesbarkeit, wobei es durchaus lesbar geschrieben werden kann, doch finde ich den "Grundaufbau" besser.

Mechanics

asc schrieb:

Delphi finde ich genauso unleserlich wie Visual Basic.

Nicht, wenn man sich dran gewöhnt hat. Hab früher jahrelang Delphi programmiert und fands viel leserlicher als Visual Basic. Jetzt hab ich das schon ewig nicht mehr programmiert und finds auch nicht mehr so toll. Aber immer noch viel besser als VB

audacia

asc schrieb:

Mehr brauche ich dazu auch nicht zu sagen

Nein, natürlich nicht. Mich haben nur die Details interessiert, weil heftige Abwehrreaktionen ("Kündigungsgrund") nach meiner Erfahrung selten rationale Gründe haben. Meistens hört man dann "ist halt so" oder "die Details sind unwichtig; geh doch weg!!1"

Unabhängig davon, was man von Delphi hält, die Arbeit mit RTL, VCL und FireMonkey aus Delphi nicht nur komfortabler (bessere IDE-Unterstützung), sondern auch viel irritationsärmer, weil diese Bibliotheken eng mit den Spracheigenschaften von Delphi verbunden sind. C++Builder ist ein sehr nützliches Werkzeug, wenn man Interop-Anforderungen mit bestehendem C++-Code hat, aber in C++Builder ist man als gelernter C++-Programmierer immer den Delphi-spezifischen Widernatürlichkeiten ausgesetzt:

Bifurkation der Objektmodelle ( TObject vs. alles andere) inklusive Abweichungen in der Konstruktions-/Destruktionsreihenfolge
keine Delphi-Klassen auf dem Stack
Ambiguität bei abstrakten Klassen, die auch als Interface-Typen benutzt werden können
RTTI (aber nur für bestimmte Typen in bestimmten Klassen)
untypische Spracherweiterungen wie __closure oder __property
unvollständig unterstützte Delphi-Sprachfeatures wie Metaklassen
auf mobilen Plattformen automatisches Lifetime-Management, wo man es nicht erwartet (d.h. manche Zeigertypen sind insgeheim Smartpointer)
...

Das hat ja alles seine Rechtfertigung, aber es ist einiges an zusätzlicher Komplexität, und nicht vielen gelingt es, dann noch sauber zwischen dem C++Builder-Dialekt und regulärem C++ zu trennen. Wäre es da nicht besser, man würde den Code, der mit den Delphi-Frameworks interagiert, soweit als möglich in Delphi schreiben, wo diese Eigenschaften natürlicher Bestandteil der Sprache sind?

Ich sehe das analog zu C# und C++/CLI. Letzteres ist sehr nützlich, wenn man mit C++-Code interagieren will, aber egal ob man C# mag oder nicht, erspart man sich doch viel Aufwand und Irritationen, wenn man die managed only-Teile seiner Anwendung in C# schreibt. In C++/CLI muß man immer darüber nachdenken, ob man jetzt gcnew oder new (oder, Gott bewahre, ref new ) schreibt, ob man da ein Template oder ein generic benutzt, oder warum manche Typen nicht als Felder in manchen Klassen benutzt werden können. Und dann ist da noch die zusätzliche Komplexität, die sich durch das abweichende Laufzeitmodell ergibt (z.B. statische Variablen in C++/CLI-DLLs garantieren tagelanges Vergnügen bei der Fehlersuche).

(Weil das auch Microsoft so sieht, ist übrigens /clr:pure ab dem kommenden VC++ deprecated.)