Compiler-Alternative neben VC und GCC



  • Gibt es eigentlich, neben Visual C++ und dem GCC (MinGW), noch einen anderen kostenlosen Compiler für Windows, der erstens standardkonform ist und zweitens auch die WinAPI-Programmierung unterstützt?



  • Borland



  • Also der C++BuilderX ist kein Stück standardkonform...



  • Kostenlose konforme Compiler gibt es kaum. Unter Windows hauptsächlich MSVC, dann ist noch GCC dabei, für die MS-Hasser. Alle anderen kostenlosen (DMC, OpenWatcom usw.) sind sehr schlecht. Was auch nicht verwunderlich ist: warum sollte man an diesen weiter entwickeln, wenn die Übermacht mit GCC und MSVC da ist?



  • Gibt es dann wenigstens eine alternative Implementierung der C++-Standard Library, die ich mit MinGW benutzen kann? Die Leute von MinGW haben die gesamte Standardbibliothek leider in eine einzelne Lib-Datei gepackt, die immer komplett mitgelinkt wird, so dass die Exe-Datei immer ziemlich groß ist:

    [quote=http://mingw.org/mingwfaq.shtml#faq-C++size]Why is my C++ binary so large?

    C++ programs using the Standard Template Library (ie/ #include <iostream>) cause a large part of the library to be statically linked into the binary. The need to statically link the stdc++ into the binary is two fold. First MSVCRT.dll does not contain C++ stdlib constructs. Second the legal implications of generating a libstdc++.dll are restricted by the licensing associated with the library. If you wish to keep your file size down use strip to remove debugging information and other verbatim found in the binary.

    strip --strip-all SOMEBINARY.exe[/quote]

    Mir gefällt die Variante von Visual C++ viel besser. Da kann das ganze auch statisch gelinkt werden (und ist somit ebenfalls von keiner DLL-Datei abhängig), aber trotzdem kommen nur die Funktionalitäten in die Exe, die auch gebraucht werden. (Aber den Visual C++-Compiler kann man leider nicht so ohne weiteres von einem USB-Stick aus benutzen, und wenn doch, dann läuft er trotzdem nicht auf älteren Betriebssystemen.)



  • Ältere Betriebssysteme?

    Dann sind vielleicht doch der Digital-Mars mit der zusätzlich installierten
    STL interessant. Openwatcom kann teilweise STL, aber die wird noch weiterentwickelt.

    Solltest du mit dem Borland free bcc5.5 arbeiten wollen, dann wirst du feststellen
    das die meisten der freien Ideen aus dem Netz diesen nicht optimal ansteuern.
    Das heist du must die Makefiles oft von Hand ergänzen.

    Aber, wenn du mit dem DEV geabreitet hast, sollten dir ähnliche Probleme bekannt
    sein.

    Ich denke entweder must du noch eingehender beschreiben was du vorhast oder du
    must selbst viel testen. z.B. Welche Betriebssysteme a.) zum compilieren und
    welche eventuell b.) anderen als Ziel?

    MfG f.-th.



  • Sinthoras schrieb:

    Also der C++BuilderX ist kein Stück standardkonform...

    Der C++BuilderX ist eine IDE und kein Compiler. Überdies erlaubt er die Verwendung praktisch jedes Compilers; neben dem BCC werden z.B. MSVC und MinGW/GCC schon von Haus aus unterstützt.

    Der BCC hat in der Tat ein paar Probleme mit der Standardkonformität. Aber "kein Stück standardkonform"? Das deckt sich keineswegs mit meinen Erfahrungen. Er hat ein paar Probleme mit Templateparametern in Funktionsschreibweise (template <typename T1, typename T2, typename T3> class Foo <T1 T2 (T3)>) und anderen sehr speziellen Sachen, aber mit dem meisten kommt er zurecht. Und ich möchte daran erinnern, daß bis vor gar nicht so langer Zeit MSVC 6.0 noch im Rennen war - und dem ist der BCC nicht nur in dieser Hinsicht deutlich überlegen 😉

    Außerdem wird der BCC durchaus noch weiterentwickelt - zwischen 2002 und 2005 war die Fortentwicklung aufgrund des ständig schwankenden Kurses von Borland in dieser Zeit recht weit zurückgefahren, aber seit dem Erscheinen des BDS 2006 wird wieder aktiv daran gearbeitet. Einige für CodeGear selbst nicht ganz unwichtige Programme (der Delphi-Compiler und der BCC selbst) wurden für den BCC geschrieben, und auch der C++Builder ist kommerziell nicht so irrelevant, wie man vielleicht meinen möchte, so daß der Compiler weiterhin für CodeGear von großem Interesse sein dürfte. Gegenwärtig richten sich die Bemühungen hauptsächlich darauf, die Standardkonformität zu verbessern und Boost möglichst vollständig zu unterstützen, nach dem Highlander-Release wird wahrscheinlich auch eine 64-Bit-Version und eine Überarbeitung des Backends kommen.

    Artchi schrieb:

    dann ist noch GCC dabei, für die MS-Hasser.

    Jawoll, der einzige Grund für den GCC 😃

    Artchi schrieb:

    warum sollte man an diesen weiter entwickeln, wenn die Übermacht mit GCC und MSVC da ist?

    😕
    Warum Linux entwickeln, wenn Microsoft schon Windows bietet?
    Vielleicht, weil es Code gibt, der von einem anderen Compiler abhängt? Weil ein anderer Compiler Möglichkeiten bietet, die es bei den Mainstreamprodukten nicht gibt?

    f.-th. schrieb:

    Solltest du mit dem Borland free bcc5.5 arbeiten wollen

    Bitte nicht. Stattdessen nimm den BCC 5.8.2, er ist in Turbo C++ Explorer enthalten.



  • Die Intel Compiler gibt es glaube ich für private Zwecke kostenlos

    @audacia
    haben die Borland-Compiler mittlerweile einen besseren Standardsupport?



  • rüdiger schrieb:

    Die Intel Compiler gibt es glaube ich für private Zwecke kostenlos

    Nur für Linux und dort IIRC nur für GPL-Projekte.

    rüdiger schrieb:

    haben die Borland-Compiler mittlerweile einen besseren Standardsupport?

    Besser als was?
    Auf jeden Fall ist die Standardunterstützung seit dem BCC 5.5 durchaus besser geworden. Alles weitere hab ich eigentlich schon geschrieben.



  • audacia schrieb:

    Artchi schrieb:

    dann ist noch GCC dabei, für die MS-Hasser.

    Jawoll, der einzige Grund für den GCC 😃

    Einen anderen kenne ich auch nicht, für Windows-Compiler.

    audacia schrieb:

    Artchi schrieb:

    warum sollte man an diesen weiter entwickeln, wenn die Übermacht mit GCC und MSVC da ist?

    😕
    Warum Linux entwickeln, wenn Microsoft schon Windows bietet?

    Was hat ein OS jetzt damit zu tun?

    audacia schrieb:

    Vielleicht, weil es Code gibt, der von einem anderen Compiler abhängt? Weil ein anderer Compiler Möglichkeiten bietet, die es bei den Mainstreamprodukten nicht gibt?

    Unter Windows nehme ich den für mich besser geeigneten Compiler. Notfalls entscheidet auch der Preis, wenn die Features sich nicht groß unterscheiden. Dummerweise gibts den MSVC kostenlos, wo der GCC erstmal ein sehr gutes Argument bringen muß, wenn ich für Windows kompilieren will.
    Und wenn ich durch Code von einem bestimmten Compiler abhängig bin, habe ich anscheinend kein ISO-C++-Sourcecode? Dann ist das C++-Compiler-Argument aber eh hinfällig.

    Welche Möglichkeiten hat denn GCC, die ich z.B. in einem "Mainstreamprodukt" (was soll das eigentlich sein? Ist de GCC nicht Mainstream, oder ist das ein Nischenprodukt?) nicht habe?

    Ich weiß ja nicht was deine Vorstellung von ISO-C++ ist. Aber ich verstehe darunter, das das Ziel ist, das ich mein C++-Programm auf jedem beliebigen C++-Compiler auf einer Platform kompilieren kann. Wenn ich ein Windows-Programm habe, möchte ich bitte auch dieses auf einem MSVC, ICC oder GCC unter Windows kompilieren können. Und mit dem MSVC kann ich das garantiert.



  • Artchi schrieb:

    Ich weiß ja nicht was deine Vorstellung von ISO-C++ ist. Aber ich verstehe darunter, das das Ziel ist, das ich mein C++-Programm auf jedem beliebigen C++-Compiler auf einer Platform kompilieren kann. Wenn ich ein Windows-Programm habe, möchte ich bitte auch dieses auf einem MSVC, ICC oder GCC unter Windows kompilieren können. Und mit dem MSVC kann ich das garantiert.

    Wenn du nur Standard-C++ verwendest, mag das gehen. Selbst dann aber kann es im Rahmen des Standards Eigenheiten verschiedener Compiler geben, so daß (z.B. bei einem Windows-Port einer Linux-Software) die Benutzung eines anderen Compilers vorteilhaft ist. Ist außerdem ein Projekt keine komplette Neuentwicklung, so kann es sinnvoll sein, die Binärkompatibilität zu erhalten - was compilerübergreifend selten bis gar nicht möglich ist.

    Tatsache ist aber, daß man sich selten ausschließlich im Rahmen des C++-Standards bewegt. Fast für alle Zwecke benutzt man ein Framework, das den direkten Umgang mit vielen systemspezifischen Angelegenheiten abstrahiert. Die MFC zum Beispiel haben einige historisch gewachsene Microsoft-spezifische Eigenheiten, außerdem verbietet die Lizenzbedingung AFAIK die Verwendung mit nicht lizenzierten Compilern. Als MFC-Nutzer bist du also bezüglich der Compilerportabilität schon recht eingeschränkt. Auch z.B. die Benutzung der VCL oder der zu deren Unterstützung im BCC verfügbaren, aber nicht im Sprachstandard enthaltenen Features (im Wesentlichen Reflection, Persistenz, Properties, Closures aka Delegates) kann durchaus sinnvoll sein, aber da hilft dir dann der MSVC-Compiler nichts mehr.


Log in to reply