Embarcadero Versionen - Wie läufts bei Euch?

Hallo,

ich stelle gerade alte VCL/bcc32-Projekte auf bcc32c (clang) um.

Vorher war's XE6, das war schon übel buggy (häufig interne compiler errors, falsche linker error/linker-abstürze, komplette IDE-Abstürze).

Mit 10.1/clang habe ich noch wenig Erfahrung, IDE ist auch schon abgestürzt aber meistens gehts.

Mit 10.2 stürzt mir die IDE bisher häufiger ab.

Wie ist das bei Euch? Wie siehts allgemein mit dem clang-Compiler aus? Gute Erfahrungen?

Hat schon mal jemand viel alten Code auf Embarcadero-clang portiert und will darüber berichten?

Also ein Punkt, der mir schon mal sehr negativ beim bcc32c auffällt:

Syntaxfehler in irgend einem Header, und man hat keine Chance herauszufinden, über welchen #include-Umweg dieser Header überhaupt in die CPP-Datei gekommen ist.
Da fehlt dann einfach mal das kleine [+] vor der Fehlermeldung um genauere Infos zu erhalten.

DocShoe

Ich trau dem Ding keinen Meter über den Weg.

- Im RAD Studio 10 Seattle gibt´s einen Bug beim Codegenerator, der UB erzeugt. Der Compiler benutzt den RValue-Konstruktor von std::string wo es nicht erlaubt ist und ~~erzeugt UB~~ löscht den Inhalt von std::strings. Totaler Showstopper, macht den Compiler unbrauchbar.

- Im RAD Studio 10.1 Berlin erzeugt der clang Compiler UB, wenn in einer Delphi Unit ein Extended auf den Stack gelegt wird. Der dcc legt 12 Byte auf den Stack und der clang holt nur 10 ab. Erzeugt ebenfalls UB.

- Im RAD Studio 10.2 Tokyo erzeugt der clang im Release Build mit den Optimierungen -O2 fehlerhaften Code. Was genau das schief läuft kann ich nicht genau sagen, aber im Prinzip baut der Compiler bei diesem Quelltext Mist:

class SomeType
{
   std::wstring Name;
   std::wstring Info;
   std::wstring Lang;
   std::wstring Timestamp;
   unsigned int CodePage;
};

void func( SomeType& st )
{
   try
   {
      do_something( st );
   }
   catch( std::exception& excp )
   {
      do_something_else( st );
   }
}

Wenn in do_something eine std::exception geworfen wird und dann do_something_else aufgerufen wird ist st kaputt. Aber so richtig, das sieht aus wie random memory. Beim Zugriff auf einen string-Member tritt eine Access-Violation auf. Tritt nur im Release Modus auf, wenn ich den catch-Block um eine Meldungsbox erweitere läuft´s auch im Release-Build:

void func( SomeType& st )
{
   try
   {
      do_something( st );
   }
   catch( std::exception& excp )
   {
      MessageBoxW( 0, st.Name, L"Name", MB_OK | MB_ICONINFORMATION );
      do_something_else( st );
   }
}

Ich kann wirklich nur ernsthaft davon abraten, das RAD Studio für die C++ Entwicklung zu benutzen. Delphi mag gehen, aber ich habe Bauchschmerzen bei C++. Ich wundere mich wirklich, wie die Tests bei Embarcadero aussehen, wenn nach zwei Jahren, 3 Major und 5 Minor Releases immer noch kritische Bugs im Codegenerator existieren.
Abgesehen davon glaube ich auch, dass es kaum noch C++ Entwickler gibt, die mit dem RAD Studio arbeiten. Ich war im Februar auf der Roadshow mit 75 Teilnehmern, von denen haben 3 mit dem RAD Studio gearbeitet. Einer davon war ich und ein anderer, mit dem ich micht unterhalten habe, meinte, dass er eigentlich nur C programmiert und diese neumodischen C++ Gimmicks wie STL und template überhaupt nicht benutzt.

Edit:
Der integrierte Debugger ist ebenfalls Käse. Teilweise braucht er 30 Sekunden und länger um auf einem Brechpunkt zu Stehen zu kommen. Außerdem zeigt er oft auch nicht alle lokalen Variablen an, und wenn er sie anzeigt teilweise mit falschen Werten.

Edit II:
Auswirkungen des Compilerbugs von 1) korrigiert

DocShoe schrieb:

class SomeType
{
   std::wstring Name;
   std::wstring Info;
   std::wstring Lang;
   std::wstring Timestamp;
   unsigned int CodePage;
};

void func( SomeType& st )
{
   try
   {
      do_something( st );
   }
   catch( std::exception& excp )
   {
      do_something_else( st );
   }
}
Wenn in do_something eine std::exception geworfen wird und dann do_something_else aufgerufen wird ist st kaputt. Aber so richtig, das sieht aus wie random memory. Beim Zugriff auf einen string-Member tritt eine Access-Violation auf. Tritt nur im Release Modus auf, wenn ich den catch-Block um eine Meldungsbox erweitere läuft´s auch im Release-Build:
void func( SomeType& st )
{
   try
   {
      do_something( st );
   }
   catch( std::exception& excp )
   {
      MessageBoxW( 0, st.Name, L"Name", MB_OK | MB_ICONINFORMATION );
      do_something_else( st );
   }
}

hmm, naja, damit kann ich jetzt nichts anfangen, das ist ja nur Pseudo-Code. Grundsätzlich habe ich mit dem alten bcc32 und std::-Exceptions auch schon schlechte Erfahrungen gemacht. Aber dein Speicherfehler hier kann ja sonst woher kommen.

Ich kann wirklich nur ernsthaft davon abraten, das RAD Studio für die C++ Entwicklung zu benutzen.

Haha, als wäre Embarcadero/VCL hier keine Notwendigkeit.
Wer das hier liest und echt noch die Wahl hat, tausende Euro zu sparen und bessere C++-Compiler zu benutzen: LAUF WEG, schau nicht zurück...

Als Anfänger habe ich gute Erfahrungen mit dem C++Builder Starter gemacht.
Hab überlegt mir die Professional Version mit Mobile-Add-On-Pack zu kaufen.

Was wäre die Alternative, MS Visual Studio?
Und welches (cross-platform) Framework?

Danke!

Plan B

DocShoe

Als Alternative auf der Windows Plattform kommt für mich eigentlich nur das MS Visual Studio infrage. Was das GUI Framework angeht kann ich dir leider nicht viel sagen, weil ich ebenfalls suche.

Windows Forms
Ist das MS GUI Toolkit und ist direkt in´s Visual Studio integriert. Ist eber kein natives C++ Framework, sondern managed C++. Das erfordert die Benutzung eigener Schlüsselwörter und ist kein reines C++ mehr. Außerdem muss das passende .NET Framework auf dem Zielrechner installiert sein.
Qt
Ist eine reines C++ Toolkit , das mehrere Plattformen unterstützt. Für die kommerzielle Nutzung fallen monatliche Gebühren an, die so lange bezahlt werden müssen, wie die Software vertrieben wird. Qt lässt sich IIRC als Add-In in das Visual Studio integrieren. Falls man das nicht möchte/kann gibt´s eine eigene IDE (QtCreator).
wxWidgets
Ein Open Source C++ Toolkit, das kostenlos in kommerziellen Projekten benutzt werden darf. Unterstützt ebenfalls mehrere Plattformen.
GTK+
Ebenfalls ein Open Source C++ Toolkit, das kostenlos in kommerziellen Projekten benutzt werden darf. Unterstützt ebenfalls mehrere Plattformen.

Irgendwo hier im Forum gibt´s einen sticky-Thread, der im Detail auf die einzelnen Toolkits eingeht, da musste mal suchen.

Ansonsten kann ich meinen Ratschlag nur wiederholen: Finger weg vom Embarcadero RAD Studio! Es kostet einfach nur Geld und Nerven. Wenn man sowas natürlich mag, weil man den Nervenkitzel braucht und unbedingt Tools benutzen möchte, die der Zeit 6 Jahre hinterherhinken*, dann greif zu!
Die RAD Studio Roadmap sieht vor, dass mit 10.3 C++17 unterstützt werden soll. Das das auf Anhieb klappt wage ich mal zu bezweifeln. Als Grundlage dafür dient der clang Compiler, den das Embarcadero Team um eigene Schlüsselwörter erweitert, um die Kompatibilität zum alten Compiler und zum eigenen Toolkit sicherzustellen. Das haben die mit dem clang 3.3.1 nach zwei Jahren immer noch nicht im Griff und ich glaube nicht, dass es mit neueren (und komplexeren) clang Versionen schneller geht.
Ein weiterer Vorteil vom Visual Studio ist die freie Verfügbarkeit. Wenn du die Community Edition benutzen darfst bekommst du die Updates und Bugfixes gratis mit einem neuen Release. Bei Embarcadero kaufst du ein Abonnement, du bekommst nur so lange Updates, wie das Abo läuft. Wenn du kein Abo hast bekommst du nicht ein Mal mehr Bugfixes. Das Visual Studio Professional musst du natürlich ebenfalls kaufen, aber es kostet aktuell nur etwa ein Viertel des RAD Studio.

Ein weiterer Punkt für das Visual Studio ist die Verfügbarkeit von 3rd Party Komponenten. Für das Visual Studio gibt es eigentlich alles, beim RAD Studio wird die Luft schon dünner. Oft gibt es die RAD Studio Sachen nur als Delphi Implementation, was in den meisten Fällen kein Problem ist, aber in manchen Fällen die Installation schwierig machen kann.

*Das RAD Studio 10.1 Update 2 von 2016 behauptet zwar, C++11 zu unterstützen, aber es hat kritische Bugs im Codegenerator, die das Tool unbrauchbar machen oder zumindest ausgiebige Tests im Release Build erfordern. Wenn sich der Release Build anders verhält als der Debug Build (abgesehen von Performance) habe ich Zweifel an der Korrektheit der Anwendung.

Braunstein

DocShoe schrieb:

Qt
... Für die kommerzielle Nutzung fallen monatliche Gebühren an, die so lange bezahlt werden müssen, wie die Software vertrieben wird. ...

Stimmt so nicht. Qt läuft unter anderem auch als LGPL. Da fallen keine Gebühren an. Man muss nur dynamisch linken, also die nötigen dlls mitgeben.

Macht für Eure Alternativen-Diskussion doch bitte einen neuen Thread auf.
Wie gesagt, wenn sich die Frage, ob Embarcadero oder nicht, stellen würde, wäre ich gar nicht hier

DocShoe schrieb:

Die RAD Studio Roadmap sieht vor, dass mit 10.3 C++17 unterstützt werden soll.

Das ist interessant... ich war ja erstmal enttäuscht, im 10.2 noch kein C++14 zu finden und habe mir bzgl. C++-Standard gar keine Hoffnungen mehr gemacht (ist allerdings auf meiner Prioritätenliste auch nicht ganz oben. C++11 wäre erstmal wichtig.)

*Das RAD Studio 10.1 Update 2 von 2016 behauptet zwar, C++11 zu unterstützen, aber es hat kritische Bugs im Codegenerator, die das Tool unbrauchbar machen oder zumindest ausgiebige Tests im Release Build erfordern. Wenn sich der Release Build anders verhält als der Debug Build (abgesehen von Performance) habe ich Zweifel an der Korrektheit der Anwendung.

OK, aber kritische Bugs habe ich von BCB5 bis XE10.2, sowohl in Compiler, Linker und besonders in der IDE (habe den Eindruck viele Bugs in Compiler/Linker werden erst durch die IDE getriggert. Wie sonst erklärt ein IDE-Neustart die Fehlerbehebung bei Syntaxfehlern???)

Konntest du denn diese Fehler einkreisen bzw. umschiffen (so wie ich es seit Jahren in den vorherigen Versionen versuche) oder von welcher Bughäufigkeit reden wir hier?

DocShoe

Nein, konnte ich nicht. Das erschreckende ist auch, dass der betreffende Code in anderen Projekten keine Probleme macht, es scheint also irgendwie auf den Kontext anzukommen. Wobei es dabei nicht so viel Kontext gibt, der tatsächliche Code hinter meinem Pseudocode ruft in do_something zwei weitere Funktionen auf und in der letzten schlägt ein CreateFile Aufruf der WinAPI fehl woraufhin die aufrufende Funktion eine exception wirft. Hat etwa die Komplexität einer Übungsuafgabe aus dem 2. Kapitel eines C++ Buchs.

Wenn das RAD Studio für dich ein no-go ist, wozu dann dieser Thread? Möchtest du wissen, ob du der einzige bist, bei dem es Probleme macht?

Kerem

Wir nutzen Version 10 Seattle Update 1 und haben einige unserer dlls auf clang umgestellt. Diese sind relativ schlank und nutzen keine VCL, was das Arbeiten mit dem Compiler erträglich macht. Fehlverhalten des erzeugten Codes konnten wir bisher nicht beobachten.

Bei einer größeren FMX-Cross-Plattform-Anwendung im Prototyp-Stadium sieht das schon anders aus. Hier stürzt die IDE regelmäßig ab, das Debuggen ist eine Qual und das Compilieren dauert eine halbe Ewigkeit, was das Verwenden der automatischen Code-Vervollständigung quasi ausschließt. Haben einiges probiert, um das ganze stabile und schneller zu machen, aber die Produktivität, die wir mit dem bcc32 + VCL haben, erreichen wir bei weitem nicht.

Ich hatte auch schon unsere gesamte Anwendung (VCL, exe + ca. 23 dlls + ca. 10 bpls) portiert, was an sich unproblematisch war. Der Compiler war zufrieden, aber wirklich arbeiten ließ sich aus oben genannten Gründen nicht damit. Auch zur Laufzeit ging einiges schief, weswegen wir uns relativ schnell vom clang abgewandt haben.

@DocShoe:

Im RAD Studio 10 Seattle gibt´s einen Bug beim Codegenerator, der UB erzeugt. Der Compiler benutzt den RValue-Konstruktor von std::string wo es nicht erlaubt ist und erzeugt UB. Totaler Showstopper, macht den Compiler unbrauchbar.

Kannst du mehr dazu sagen oder eine Quelle nennen? Ich bin etwas besorgt, da wir gerade erst einige dlls umgestellt haben. Ich war übrigens auch auf der Roadshow und bin enttäuscht wieder heimgefahren.

DocShoe

Wenn du einen EDN Account hast kannst du dir den Fall unter RSP-13813 angucken.

Ist schon ne Weile her und ich hatte das Verhalten falsch in Erinnerung. Der Compiler erzeugt kein UB, sondern löscht den Inhalt von std::strings.

Danke für die Antworten. Das klingt ja alles gar nicht gut.

Bin jetzt noch auf einen Bug gestoßen, dass "make" nicht funktioniert und die IDE stattdessen immer wieder einen kompletten "rebuild" des Projekts anstößt (selbst wenn man nur eine .cpp-Datei angefasst hat). Weiß noch nicht wodurch das getriggert wird aber wenn dass häufiger/immer auftritt, wäre das alleine schon ein KO-Kriterium.

Ich verstehe nicht, wie die diese ohnehin schon verbuggte IDE, jetzt nochmal so viel schlimmer gemacht haben. Qualitätskontrolle scheints da überhaupt nicht zu geben??

DocShoe schrieb:

Wenn das RAD Studio für dich ein no-go ist, wozu dann dieser Thread? Möchtest du wissen, ob du der einzige bist, bei dem es Probleme macht?

Habe ja geschrieben, dass ich vor vorhandenen (VCL-)Projekte sitze die ich gerne auf den neuen Compiler umgestellt hätte. Wenn ich was ganz neues anfangen würde und die Wahl hätte, wäre Embarcadero absolutes no-go.

DocShoe

Erfahrungsberichtesucher schrieb:

Bin jetzt noch auf einen Bug gestoßen, dass "make" nicht funktioniert und die IDE stattdessen immer wieder einen kompletten "rebuild" des Projekts anstößt (selbst wenn man nur eine .cpp-Datei angefasst hat). Weiß noch nicht wodurch das getriggert wird aber wenn dass häufiger/immer auftritt, wäre das alleine schon ein KO-Kriterium.

Nicht nur das. Es passiert auch hin und wieder, dass die IDE Änderungen an einer .cpp Datei nicht mitbekommt und die .cpp Datei nicht neu übersetzt. Der Linker linkt dann fröhlich gegen die alte .obj Datei und zur Laufzeit bleibt deine Anwendung mit einer Fehlermeldung stehen.