Embarcadero Versionen - Wie läufts bei Euch?



  • 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



  • 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.

    1. 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.

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

    3. wxWidgets
      Ein Open Source C++ Toolkit, das kostenlos in kommerziellen Projekten benutzt werden darf. Unterstützt ebenfalls mehrere Plattformen.

    4. 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.



  • DocShoe schrieb:

    1. 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?



  • 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?



  • 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.



  • 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.



  • 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.


Anmelden zum Antworten