Compiler



  • Hallo zusammen,

    vor 12 Jahren habe ich meine Aktivitäten stark eingeschränkt.
    Jetzt, nachdem ich meinen Rechner neu aufgestellt habe (WIN 2K und Borland Builder 6) möchte ich weiter machen.
    Beim Versuch ein bestehendes Projekt zu kompilieren kommt die Fehlermeldung:
    "Expected a FileName"
    Ich vermute meine Wege in den Optionen stimmen nicht.
    Aber ich habe den Rechner genau wieder so aufgebaut wie es vorher war (meine Verzeichnisse sind die gleichen).
    Kann mir jemand einen Tip geben ???
    LG
    Traugott



  • Kann mir jemand einen Tip geben ????

    Außer kauf dir was Neues? Nein.



  • Mal kurz gegoogelt, scheint ein Linker Fehler zu sein, vor allem, wenn "ungültige" Zeichen im Pfad sind.
    Versuch das Projekt zu verschieben, oder notfalls neu anzulegen.



  • @Traugott sagte in Compiler:

    Jetzt, nachdem ich meinen Rechner neu aufgestellt habe (WIN 2K und Borland Builder 6) möchte ich weiter machen.

    Holla die Waldfee, ich hoffe du hast nicht vor diesen Rechner zu nutzen. Zwischen Win 2K und Win10 und Borland Builder 6 und C++20 liegen Welten.



  • An dieser Stelle möchte ich ausdrücklich vor Borland/Embarcadero/Idera warnen. Das Einzige, was die können, ist Marketing. Als C++ Compiler wird clang eingesetzt, was an sich eine gute Idee ist, aber deren Framework (die VCL) ist Pascal, also setzt sich ein externes Team an den clang Quelltext und baut da eigene Keywords ein, um das VCL Framework zu unterstützen. Statt einen Präprozessor davorzuschalten, der die Anpassung macht, wir der clang-Quelltext angefasst. Das hat mehrere Konsequenzen:
    Man hängt der aktuellen Entwicklung immer hinterher, da neue clang Versionen angepasst und getestet werden müssen, bevor sie in das RAD Studio integriert werden. Obwohl ich manchmal den Eindruck habe, dass da nichts mehr getestet wird. It compiles? Ship it! Der C++11 Standard von 2011 wurde erst 2017 ins RAD Studio integriert und brauchte 3 Major Releases, um halbwegs fehlerfrei zu sein. Wir haben in unseren Projekten zwei echte Showstopper gehabt:

    • Falsches Anwenden der move-Semantik führte dazu, dass ein String bei der Übergabe als non-const Referenz gemoved und dabei zerstört wurde. Ohne Compilerwarnung oder Fehlermeldung, deine Anwendung fliegt dir zur Laufzeit einfach um die Ohren.
    void boom( String& s )
    {
    }
    
    int main()
    {
       String s = "Hello World";
       boom( s );
       // s ist ab hier kaputt. Kaputt im Sinne von Objekt zerstört
    }
    
    • Unterschiedliche Datentypgrößen in Delphi und C++. Wie gesagt, das VCL Framework ist in Delphi programmiert und hat ein C++ Binding. An Delphi wird wohl regelmäßig rumgeschraubt, und da hat man wohl vergessen, das in C++ anzupassen. Lange Rede, kurzer Sinn: Delphi legt einen 10-Byte Extended Double auf den Stack, C++ holt einen 8-Byte double ab => boom! Wieder ganz ohne Compilerwarnung oder Fehlermeldung, deine Anwendung fliegt dir zur Laufzeit wieder um die Ohren.

    Ich habe beide Bugs an Embarcadero berichtet, hab da nie wieder was von gehört. Kostenloser Bugfix? Pustekuchen, ohne Subscription muss man das Upgrade kaufen, selbst bei kritischen Bugs.

    • Der Debugger verhaspelt sich regelmäßig und vergisst Variablen und deren Inhalte. Ärgerlich beim Debuggen, wenn der Debugger die aktuellen Variablen und deren Inhalt nicht anzeigen kann. Das Problem trat beim RAD Studio 10.0 auf und wurde mit 10.1 gefixt. Mit 10.2 wurde es dann wohl "richtig" gefixt. Selbstverständlich muss man das Upgrade ohne Subscription wieder kaufen.

    • RAD Studio 10.2: Der Compiler kann out of the Box keine 64bit C++ Anwendungen erzeugen, weil beim Linken irgendwelche Heaps überlaufen. Die Kommandozeilenparameter um den entsprechenden Heap zu vergrößern werden nicht ausgewertet, also kann man mit dem 10.2 keine 64bit C++ Anwendungen erzeugen.

    • Support gibt´s effektiv nur gegen Bezahlung. Borland/Embarcadero/Idera verfolgt ein Subscription Modell, bei dem man das Produkt einmalig kauft und dann jährlich eine Subscription Gebühr bezahlt, die zum Update/Upgrade berechtigen. Aktuell gibt´s zum Major zwei Minor Releases/Updates, wenn´s dann immer noch Bugs gibt muss man halt ein Major Update machen (falls man dazu berechtigt ist). Selbst bei katastrophalen Bugs (siehe oben) bekommt man ohne Subscription kein Update).

    • An Delphi wird wohl häufig iwas geändert und man nimmt dabei keine Rücksicht auf Abwärtskompatibilität. Für das RAD Studio werden die meisten Zukaufkomponenten aber als Delphi Komponeten mit C++ Binding angeboten. Wenn man also das RAD Studio aktualisiert muss man häufig auch die zugekauften Bibliotheken aktualisieren. Je nach Anzahl der Bibliotheken und der Entwickler kostet das jährlich mal schnell 20-30.000 Euro. Und dann kann es durchaus passieren, dass beim Anpassen des clang Compilers für die Delphi Unterstützung wieder neue Bugs dazukommen. Haben wir so schon alles erlebt, deswegen setzen wir atm das RAD Studio 10.1 ein, weil da "nur" der Debugger kaputt ist und die IDE bei der Codevervollständigung manchmal in´s Nirvana verschwindet. Beim Upgrade auf eine neue Version spielt man Russisch Roulette.

    • Ich habe den Eindruck, dass bei Borland/Embarcadero/Idera Augenwischerei betrieben wird, man möchte iwie alles und jeden bedienen, liefert aber ein technisch unzureichendes Produkt ab. Wenn man in C++ schnell eine Minianwendung mit drei oder vier Fenstern basteln möchte reicht das aus, für große Projekte kann ich das ernsthaft niemandem empfehlen.

    Wenn du C++ machen möchtest:
    UM GOTTES WILLEN FINGER WEG VOM BORLAND/EMBARCADERO/IDERA RAD STUDIO! WIRKLICH!
    Nimm was anderes, egal was, aber nimm was anderes.

    Hach, die Woche fängt gut an :))



  • @DocShoe Was mich an Deinen Ausführungen interessiert, warum nutzt Ihr noch diese IDE und den Compiler?
    Wir hatten keine Probleme, auf eine anderen Compiler umzusteigen. Die GUI haben wir auf Qt portiert, da irgendwie ähnlich.



  • @Helmut-Jakoby

    • 30 Jahre lang gewachsener Code, keine Trennung zwischen Logik und GUI.
    • Intern werden oft Delphi Datentypen wie String, TDateTime und Variant benutzt, das müsste auch alles angefasst werden.
    • Div. Anwendungen mit zusammen sicher mehr als 1.000 Formularen, die alle umgestellt werden müssten.

    Qt war schon im Gespräch, aber da kommt nur die Pro Variante infrage, und das ist uns zu teuer.
    Wir machen jetzt Versuche mit C# und WPF, das sieht vielversprechend aus, zumindest für Desktop-Anwendungen.



  • @DocShoe Wie kann denn Qt zu teuer sein bei den Kosten und Zuständen, die du schilderst? Das versteh ich jetzt gar nicht.



  • @Tyrdal sagte in Compiler:

    @DocShoe Wie kann denn Qt zu teuer sein bei den Kosten und Zuständen, die du schilderst? Das versteh ich jetzt gar nicht.

    Ist ja nicht so, dass man heute teure Lizenzen (Qt) kauft, und die angemerkten Kosten und Zustände sind dann morgen weg ...



  • Stimmt, aber durch immer gleich weitermacxhen ändert sich erst recht nichts. Und man kann ja richtigrum anfangen, also zuerst Logik von Gui trennen. Dann wird es einfacher den Rest Schrittweise zu machen.



  • Wir haben unsere Software auch vor Jahren schon vom BCB auf Qt umgestellt. Das lief aber prinzipiell auf neu schreiben hinaus. Das ist schon ein ziemlicher Aufwand, der sich aber lohnt. Das lief dann ungefähr so, dass Einer aus dem Team den Support für den Borland / Embarcadero Kram übernommen hat (meist ich) und die Anderen das Neu schreiben. Als das dann lief bin ich auch auf Qt umgestiegen. Wir hatten aber immer schon recht wenig reine Delphi Anteile. Das meiste war schon in C++.



  • @Braunstein sagte in Compiler:

    Wir haben unsere Software auch vor Jahren schon vom BCB auf Qt umgestellt. Das lief aber prinzipiell auf neu schreiben hinaus.

    Neu schreiben ist extrem gefährlich, insbesondere bei großen Projekten. Neu geschrieben => neue Bugs. Außerdem sind alle Entwickler, die "neu schreiben", dann die ganze Zeit nicht dabei, neue Features für das Produkt zu entwickeln. Irgendwann ist dann Zeit für ein neues Release, das z.B. 1 oder 2 Jahre später rauskommt und für den Kunden keinen Mehrwert bietet, aber dafür möglicherweise neue Bugs enthält oder auch alte Bugs, die schon lange gefixt waren, wieder enthält (weil z.B. für diesen Fall nie ein Test exisitert hat).

    Ich möchte also generell davor warnen, das auf die leichte Schulter zu nehmen.

    Natürlich ist oft irgendwo ein Refactoring oder gar neu schreiben nötig, aber bitte nicht gleich alles auf einmal. Das geht schief.



  • @wob sagte in Compiler:

    Neu schreiben ist extrem gefährlich, insbesondere bei großen Projekten. Neu geschrieben => neue Bugs

    Da wir im letzten Jahr fast so was gemacht haben, kann ich das nur bestätigen. Ein Jahr kaum neue Features und hinterher ein paar unschöne Bugs, die es vorher nicht gab.

    Dafür sind wir aber jetzt schneller: Schneller beim implementieren neuer Features, schneller bei Anpassungen von altem Code und frei irgendwann mal eine neue GUI drauf zu setzen (wir machen noch klassisch Desktop, aber ein Webinterface soll auch irgendwann mal her).

    In der Summe war es bei uns nötig um die alte Basis wartbar und Teile testbarer zu machen.

    Ich kann vollkommen verstehen, wenn irgendwann der Schmerz so groß ist, dass man so ein Projekt angeht und es kann sich lohnen.



  • Wer seine Projekte nicht in kurzen Zyklen an neue Entwicklungen (Compiler, Bibliotheken etc. und nicht zuletzt neuen Erkenntnissen) anpasst hat natürlich nach einigen Jahrzehnten mit einem erheblichen Reparatur- und Erweiterungsstau zu kämpfen.
    Nicht nur, dass es sich die Lieferanten von Tools gerne bezahlen lassen, wenn ein Kunde einfach nicht auf den alten Plunder verzichten kann (man erinnere sich an die jahrelange weiter Nutzung und Wartung von Windows XP in den Behörden, hat Millionen verschlungen), sondern es gehen bisweilen auch gute Entwickler von der Fahne, da sie ihre persönliche Weiterentwicklung durch Nicht Einsatz von neuen Werkzeugen eingeschränkt sehen.
    Es hat sich in einigen Unternehmen bewährt, durch permanente (in kurzen Zeitabständen) Modernisierung seiner Projekte einerseits seine Mannschaft zu motivieren, sondern auch so etwas wie „Wir müssen alles ganz schnell umstellen, ab Zeitpunkt X läuft unsere Anwendung nicht mehr mit Y“ zu vermeiden.
    Umso länger man eine Modernisierung aufschiebt, umso teurer wird diese. Irgendwann ist es dann gar nicht mehr möglich und man wird von anderen überholt.
    <Klugscheiß ende>
    @Traugott Mein Tipp an Dich, halt Dich nicht mit dem alten Kram auf. Nutze ein modernes Betriebssystem und einen aktuellen Compiler.



  • @wob sagte in Compiler:

    Neu schreiben ist extrem gefährlich, insbesondere bei großen Projekten. Neu geschrieben => neue Bugs.

    Natürlich ist oft irgendwo ein Refactoring oder gar neu schreiben nötig, aber bitte nicht gleich alles auf einmal. Das geht schief.

    Wenn man das GUI Framework wechselt muss man viel neu schreiben. Außerdem ist das eine gute Möglichkeit Code zu entschlacken. Wenn man viele Jahre an einen Programm schreibt neigt der Code manchmal dazu unübersichtlich zu werden. Besonders wenn die Entwickler wechseln.
    Klar erzeugt man neue Bugs. Das passiert beim Einbau neuer Features in Bestandssoftware aber auch.
    Wir habens gemacht und es hat funktioniert.



  • @Tyrdal sagte in Compiler:

    @DocShoe Wie kann denn Qt zu teuer sein bei den Kosten und Zuständen, die du schilderst? Das versteh ich jetzt gar nicht.

    Naja, im Moment haben wir keine laufenden Kosten, es funktioniert ja alles mehr oder weniger.
    Mit der Debuggerschwäche kommen wir halbwegs klar. Und ich denke, dass auch das VS Studio und Qt ihre Macken haben.



  • Wenn grad alles so ruhig läuft, ist das ja die Gelegenheit ein Reengineering der angesprochenen Anwendung vorzunehmen.
    Wenn Ihr Eure Anwendung noch nicht aufgegeben habt, also diese noch weitere Jahre verkaufen wollt, müsst Ihr da sowieso mal ran.



  • @DocShoe sagte in Compiler:

    Mit der Debuggerschwäche kommen wir halbwegs klar. Und ich denke, dass auch das VS Studio und Qt ihre Macken haben.

    Aber nicht so heftige wie du sie oben beschrieben hast. Im Großen und Ganzen funktionieren die beiden schon gut.



  • Ich verwende zum Programmieren in Qt lieber den Creator. Ich finde ihn besser benutzbar als das Visual Studio. Außerdem ist man dann auch nicht mehr an das OS gebunden. Ich selber arbeite auf Windows. Meine Kollegen auf Linux. Alles am gleichen Projekt ohne größere Probleme.


Log in to reply