A
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.)
