MinGWs Zukunft?



  • Artchi schrieb:

    hibbes schrieb:

    MinGW wird halt immer dann gerne genommen wenn man sich nicht auf ein OS festlegen möchte. Unter Linux ist GCC ja eh DER Compiler und unter Darwin OSX weiß ich es nicht.

    Was hat das mit dem OS zu tun? Das Argument habe ich noch nie verstanden. Wenn ich den MSC benutze, kann ich trotzdem OS-unabhängig programmieren. Der MSC hat ja die C++-Standard-Library mit TR1.

    Und wenn ich die Windows API nutze, ist das Argument eh hinfällig. Und wenn ich z.B. wxWidgets mit MSC benutze, wird der Code eh unter Linux neu kompiliert werden müssen, dann halt mit GCC.

    Also, das Argument pro MinGW verstehe ich nicht. 😕

    Der GCC hat halt einen deutlich besseren Standard C++ Support, als der MSVC und auch der Support von C++0x ist schon viel weiter (und TR1-Support gab es auch schon, als der MSVC keinen hatte). Außerdem gibt es zwischen den Compilern ja immer kleine Unterschiede und verschiedene Erweiterungen. Daher ist es für die platformunabhängige Entwicklung praktischer, wenn man den gleichen Compiler auf allen Systemen nutzt und sich nicht auch noch mit Compilerunterschieden rumschlagen muss.



  • Einen Debugger WinDbg gibt es kostenlos:
    http://www.microsoft.com/whdc/devtools/debugging/default.mspx
    Da ist auch der Console-Debugger CDB aus dem VisualC++ dabei. Und ich sehe auch gerade im CB-Settings, das CB anscheinend den CDB unterstützt. Kann ich aber gerade nicht ausprobieren.



  • rüdiger schrieb:

    Artchi schrieb:

    hibbes schrieb:

    MinGW wird halt immer dann gerne genommen wenn man sich nicht auf ein OS festlegen möchte. Unter Linux ist GCC ja eh DER Compiler und unter Darwin OSX weiß ich es nicht.

    Was hat das mit dem OS zu tun? Das Argument habe ich noch nie verstanden. Wenn ich den MSC benutze, kann ich trotzdem OS-unabhängig programmieren. Der MSC hat ja die C++-Standard-Library mit TR1.

    Und wenn ich die Windows API nutze, ist das Argument eh hinfällig. Und wenn ich z.B. wxWidgets mit MSC benutze, wird der Code eh unter Linux neu kompiliert werden müssen, dann halt mit GCC.

    Also, das Argument pro MinGW verstehe ich nicht. 😕

    Der GCC hat halt einen deutlich besseren Standard C++ Support, als der MSVC und auch der Support von C++0x ist schon viel weiter (und TR1-Support gab es auch schon, als der MSVC keinen hatte). Außerdem gibt es zwischen den Compilern ja immer kleine Unterschiede und verschiedene Erweiterungen. Daher ist es für die platformunabhängige Entwicklung praktischer, wenn man den gleichen Compiler auf allen Systemen nutzt und sich nicht auch noch mit Compilerunterschieden rumschlagen muss.

    Wobei Standardkonformer Code in fast allen Fällen auf GCC und MSVC läuft, nicht Standardkonformer aber oft nicht auf beiden, ist es also wahrscheinlicher, das der Code Standardkonform ist, wenn er auf beiden läuft. Insofern ist es durchaus sehr sinnvoll, als Programmierer Platformunabhängigen Code auch andere Compiler als GCC zu berücksichtigen, weil die Unabhängigkeit des Codes von System und Compiler dadurch nur steigen kann.



  • Ich entwickle wie gesagt unter MSC. Wenn ich einen Meilenstein habe, baue ich unter MinGW (mache alles mit bjam). Und meistens meckert der MinGW zwei Sachen an:
    fehlende 'typename' und using namespace für std::tr1::placeholders.
    Die korrigiere ich dann, und es funktioniert dann in beiden Compilern.

    Ich sehe das so: der MSC versteht beides. Der MinGW ist restriktiver. Die nötigen Änderungen sind minimal und auf Anhieb ersichtlich. Wäre besser wenn der MSC auch restriktiver wäre. Aber deshalb auf den MSC verzichten und somit auf Windows API der neuesten Generation?



  • MinGW ist tot. Seit langem.

    rüdiger schrieb:

    Artchi schrieb:

    hibbes schrieb:

    MinGW wird halt immer dann gerne genommen wenn man sich nicht auf ein OS festlegen möchte. Unter Linux ist GCC ja eh DER Compiler und unter Darwin OSX weiß ich es nicht.

    Was hat das mit dem OS zu tun? Das Argument habe ich noch nie verstanden. Wenn ich den MSC benutze, kann ich trotzdem OS-unabhängig programmieren. Der MSC hat ja die C++-Standard-Library mit TR1.

    Und wenn ich die Windows API nutze, ist das Argument eh hinfällig. Und wenn ich z.B. wxWidgets mit MSC benutze, wird der Code eh unter Linux neu kompiliert werden müssen, dann halt mit GCC.

    Also, das Argument pro MinGW verstehe ich nicht. 😕

    Der GCC hat halt einen deutlich besseren Standard C++ Support, als der MSVC und auch der Support von C++0x ist schon viel weiter (und TR1-Support gab es auch schon, als der MSVC keinen hatte). Außerdem gibt es zwischen den Compilern ja immer kleine Unterschiede und verschiedene Erweiterungen. Daher ist es für die platformunabhängige Entwicklung praktischer, wenn man den gleichen Compiler auf allen Systemen nutzt und sich nicht auch noch mit Compilerunterschieden rumschlagen muss.

    Wenn du mir einen brauchbaren GCC für Windows x64 gibst, den man nicht vorher noch Tage lang konfigurieren muss, bevor man damit ein "Hallo Welt"-Programm kompilieren kann, bekommt der GCC bei mir vielleicht eine Chance. Ansonsten ist und bleibt GCC unter Windows für mich eine umsonst hoch gelobte Vaporware.

    Desweiteren verstehe ich nicht, warum der Standard C++ Support beim GCC "deutlich" besser sein soll als beim Visual C++. Hast du diese Aussage auf Visual C++ 2010 bezogen? Gibt es eine aktuelle Liste, wo diese Unterschiede festgehalten sind? Das würde mich sehr interessieren...



  • Artchi schrieb:

    Ich entwickle wie gesagt unter MSC. Wenn ich einen Meilenstein habe, baue ich unter MinGW (mache alles mit bjam). Und meistens meckert der MinGW zwei Sachen an:
    fehlende 'typename' und using namespace für std::tr1::placeholders.
    Die korrigiere ich dann, und es funktioniert dann in beiden Compilern.

    Ich sehe das so: der MSC versteht beides. Der MinGW ist restriktiver. Die nötigen Änderungen sind minimal und auf Anhieb ersichtlich. Wäre besser wenn der MSC auch restriktiver wäre. Aber deshalb auf den MSC verzichten und somit auf Windows API der neuesten Generation?

    Warum solltest Du auf Fortschrittlichkeit verzichten? Wenn Du den Fortschritt willst, dann musst Du halt auf veraltete Compiler verzichten.

    Und zum Thema Standardkonformität (wobei ich nicht völlig sicher bin, das der Standard es erlaubt, in jedem Fall bringt es den Nutzer dazu, gefährlich zu programmieren): MinGW in Version 4.4 (PrettyOS-Crosscompiler, dort habe ich das festgestellt) erlaubt es dem Nutzer, Variablen in Headern zu definieren und gibt keine Linkerfehler, auch wenn der Header in mehrere C-Dateien eingebunden wird. Er interpretiert das zudem als _eine_ Variable. Daraus folgere ich weiter (da includes reine textersetzung sind), das der MinGW es erlaubt, Variablen gleichen Namens in mehreren C-Dateien zu definieren die dann zu einer Variable verschmelzen. In den meisten Fällen ist sowas ein Versehen und der Nutzer kriegt keinen Linkerfehler (Auch keine Warnung) und wundert sich über unerklärliches Verhalten seines Programms.
    MSVC verhält sich da besser: Wenn im Header das extern fehlt (und die Variable muss zudem in einer C-Datei definiert werden), gibts einen Linkerfehler wegen Mehrfachdefinition.



  • Mr X schrieb:

    Warum solltest Du auf Fortschrittlichkeit verzichten? Wenn Du den Fortschritt willst, dann musst Du halt auf veraltete Compiler verzichten.

    Ja, es ist auch mein Ziel eine moderne Bibliothek zu erstellen. Also "ab mit den alten Zöpfen!". Ich hätte wirklich hier im Forum fragen sollen, bevor ich GDI+ aus Panik raus geschmissen habe.
    Ich hätte ehrlich nicht damit gerechnet, das die Mehrheit dafür ist, den MinGW nicht zu unterstützen. Habe beim Schreiben des Postings eher gedacht, ich werde für meine Frage gelyncht. 😃



  • Mr X schrieb:

    Und zum Thema Standardkonformität (wobei ich nicht völlig sicher bin, das der Standard es erlaubt, in jedem Fall bringt es den Nutzer dazu, gefährlich zu programmieren): MinGW in Version 4.4 (PrettyOS-Crosscompiler, dort habe ich das festgestellt) erlaubt es dem Nutzer, Variablen in Headern zu definieren und gibt keine Linkerfehler, auch wenn der Header in mehrere C-Dateien eingebunden wird. Er interpretiert das zudem als _eine_ Variable. Daraus folgere ich weiter (da includes reine textersetzung sind), das der MinGW es erlaubt, Variablen gleichen Namens in mehreren C-Dateien zu definieren die dann zu einer Variable verschmelzen. In den meisten Fällen ist sowas ein Versehen und der Nutzer kriegt keinen Linkerfehler (Auch keine Warnung) und wundert sich über unerklärliches Verhalten seines Programms.

    Betrifft nur Kernelbauer, fürchte ich. Mir ist das noch nie passiert.



  • Artchi schrieb:

    volkard schrieb:

    Geht es nur darum, daß die Header-Files nicht da sind? Die Windows-DLLs müßten doch gehen. Wenn Du eigene Header pflegst und nach und nach nur die Funktionen reinmachst, die Du brauchst, geht das ganz schmerzfrei, oder?

    Die GDI+ Libs hatte ich schon mal per Internet-Anleitung für den MinGW angepasst. Man mußte so um die zwanzig Zeilen im <gdiplus.h> ändern. Weiterhin braucht man ja auch eine gdiplus.a-Datei, obwohl es nur eine gdiplus.lib von MS gibt, auch wenn die Implementierung in einer DLL ist. Die .lib kann man mit einem Tool nach .a konvertieren.

    Letztendlich könnte ich ein paar Signaturen von Klassen und Funktionen ausliefern. Aber die .a muß man noch besorgen.

    Aber dann denke ich mir: warum muß ich die fehlenden Libs pflegen? Ich habe schon mit meiner Lib genug Arbeit. Ganz davon abgesehen, das ich den MinGW pers. nicht nutze. Man müsste eigentlich so denken: wer meine Lib mit seinem MinGW nutzen will, kann ja die Arbeit machen.

    Ja, das ist kein Problem.
    Nur fummelt MS immer Tücken in die Sprache rein, sodaß Du bald MS-C++ schreibst, und die Lib nicht mehr auf GCC compilierbar ist. Dann hast Du Dich so weit entfernt, daß es erst wieder ein Zurück gibt, wenn sie sehr viele Nutzer hat. Außerdem habe ich den Eindruck, daß die MinGW-Nutzer eher bereit sind, deine Lib mal auszuprobieren. Mein Tip: Mach die bedingte Compilierung um die Sprachfeatures, die bei MS vom Standard abweichen, damit später mal der liebe Porter eine reelle Chance bekommt.



  • Behauptet nicht jeder von den Besonderheiten seines ( bevorzugten ) Compilers:
    its not a bug its a feature 🤡



  • Mr X schrieb:

    Und zum Thema Standardkonformität (wobei ich nicht völlig sicher bin, das der Standard es erlaubt, in jedem Fall bringt es den Nutzer dazu, gefährlich zu programmieren): MinGW in Version 4.4 (PrettyOS-Crosscompiler, dort habe ich das festgestellt) erlaubt es dem Nutzer, Variablen in Headern zu definieren und gibt keine Linkerfehler, auch wenn der Header in mehrere C-Dateien eingebunden wird. Er interpretiert das zudem als _eine_ Variable. Daraus folgere ich weiter ... blabla

    Ich weiss jetzt natürlich nicht, ob es standardkonform ist oder nicht... Aber es gibt ja einen Unterschied zwischen einer Variablendeklaration und einer Variablendefinition. Bist Du sicher, Du hast eine Variable definitiert (mit Initialisierungswert)?
    Ich vermute, Du meinst eher die Variablendeklaration (Variable deklariert ohne Initialisierungswert). Auf diese Weise erscheint die Variable in den betroffenen Objektdateien als "common symbol" und das Verhalten des GNU Linkers ld (und der anderen 😕 ) damit ist http://sourceware.org/binutils/docs/as/Comm.html#Comm

    ... When linking, a common symbol in one object file may be merged with a defined or common symbol of the same name in another object file. If ld does not see a definition for the symbol – just one or more common symbols – then it will allocate length bytes of uninitialized memory. ...



  • abc.w schrieb:

    Mr X schrieb:

    Und zum Thema Standardkonformität (wobei ich nicht völlig sicher bin, das der Standard es erlaubt, in jedem Fall bringt es den Nutzer dazu, gefährlich zu programmieren): MinGW in Version 4.4 (PrettyOS-Crosscompiler, dort habe ich das festgestellt) erlaubt es dem Nutzer, Variablen in Headern zu definieren und gibt keine Linkerfehler, auch wenn der Header in mehrere C-Dateien eingebunden wird. Er interpretiert das zudem als _eine_ Variable. Daraus folgere ich weiter ... blabla

    Ich weiss jetzt natürlich nicht, ob es standardkonform ist oder nicht... Aber es gibt ja einen Unterschied zwischen einer Variablendeklaration und einer Variablendefinition. Bist Du sicher, Du hast eine Variable definitiert (mit Initialisierungswert)?
    Ich vermute, Du meinst eher die Variablendeklaration (Variable deklariert ohne Initialisierungswert). Auf diese Weise erscheint die Variable in den betroffenen Objektdateien als "common symbol" und das Verhalten des GNU Linkers ld (und der anderen 😕 ) damit ist http://sourceware.org/binutils/docs/as/Comm.html#Comm

    ... When linking, a common symbol in one object file may be merged with a defined or common symbol of the same name in another object file. If ld does not see a definition for the symbol – just one or more common symbols – then it will allocate length bytes of uninitialized memory. ...

    Das war aber ein großer Haufen.
    Ja, ich bin sicher.
    Auch ohne Initialisierungswert ist es eine Definition.



  • Mir fallen Variadic Templates als Vorteil von MinGW ein. Hatte zuerst mit MinGW programmiert und dann kam das böse Erwachen als ich den Code mit Visual C++ 2010 kompilieren wollte und feststellen, dass er Variadic Templates nicht unterstützt.



  • volkard schrieb:

    abc.w schrieb:

    bla blu furz

    Das war aber ein großer Haufen. ...

    Ein Haufen von mir 😕
    Kann nicht sein 😉



  • Variadic Templates schrieb:

    Mir fallen Variadic Templates als Vorteil von MinGW ein. Hatte zuerst mit MinGW programmiert und dann kam das böse Erwachen als ich den Code mit Visual C++ 2010 kompilieren wollte und feststellen, dass er Variadic Templates nicht unterstützt.

    Keine Schande. Denn der C++0x ist noch nicht draußen.



  • abc.w schrieb:

    ... und das Verhalten des GNU Linkers ld (und der anderen 😕 ) ...

    Ist jetzt Haarspalterei, aber das Verhalten des MS Linkers ist das gleiche. Habs einmal mit mingw und einmal mit MSVS 2008 Express Edition getestet.

    header.h

    #if 1
    int a;    /* No linker errors */
    #else
    int a = 0;    /* Linker reports error */
    #endif
    

    a.c

    #include "header.h"
    
    void a_set(void)
    {
        a = 1;
    }
    
    int a_get(void)
    {
        return a;
    }
    

    b.c

    #include "header.h"
    
    void b_set(void)
    {
        a = 2;
    }
    
    int b_get(void)
    {
        return a;
    }
    

    main.c

    #include <stdio.h>
    #include "header.h"
    
    extern void a_set(void);
    extern int a_get(void);
    extern void b_set(void);
    extern int b_get(void);
    
    int main(int argc, char* argv[])
    {
        argc = argc;
        argv = argv;
    
        a = 3;
        printf("a = %d, a_get = %d, b_get = %d\n", a, a_get(), b_get());
    
        return 0;
    }
    

    Makefile für mingw:

    CC = mingw32-gcc
    WARN = -Wall -Wextra -pedantic -Werror
    
    all:
    	$(CC) -c a.c -o a.o $(WARN)
    	$(CC) -c b.c -o b.o $(WARN)
    	$(CC) -c main.c -o main.o $(WARN)
    	$(CC) a.o b.o main.o -o main $(WARN)
    

    mingw32-gcc.exe (GCC) 3.4.5 (mingw-vista special r3)



  • Artchi schrieb:

    Variadic Templates schrieb:

    Mir fallen Variadic Templates als Vorteil von MinGW ein. Hatte zuerst mit MinGW programmiert und dann kam das böse Erwachen als ich den Code mit Visual C++ 2010 kompilieren wollte und feststellen, dass er Variadic Templates nicht unterstützt.

    Keine Schande. Denn der C++0x ist noch nicht draußen.

    Aber Variadic Templates sind sehr nützlich, auch wenn C++0x noch nicht draußen ist. Auch auto und decltype verwende ich oft.

    Ich wollte halt nur ein Beispiel nennen, wo MinGW VC++ was voraus hat.



  • Verbessert mich wenn ich falsch liege, aber das einzige was in diesem Thread als Nachteil des MinGW genannt wurde ist das fehlende GDI+ . Was habt ihr also gegen MinGW?



  • /rant/ schrieb:

    MinGW ist tot. Seit langem.
    Wenn du mir einen brauchbaren GCC für Windows x64 gibst, den man nicht vorher noch Tage lang konfigurieren muss, bevor man damit ein "Hallo Welt"-Programm kompilieren kann, bekommt der GCC bei mir vielleicht eine Chance. Ansonsten ist und bleibt GCC unter Windows für mich eine umsonst hoch gelobte Vaporware.

    Desweiteren verstehe ich nicht, warum der Standard C++ Support beim GCC "deutlich" besser sein soll als beim Visual C++. Hast du diese Aussage auf Visual C++ 2010 bezogen? Gibt es eine aktuelle Liste, wo diese Unterschiede festgehalten sind? Das würde mich sehr interessieren...

    Eine Entwicklungsumgebung mit GCC für Windows x64 gibt es z.B. hier:

    http://www.gordon-taft.net/SciencePack.html



  • player424 schrieb:

    Verbessert mich wenn ich falsch liege, aber das einzige was in diesem Thread als Nachteil des MinGW genannt wurde ist das fehlende GDI+ . Was habt ihr also gegen MinGW?

    Das er mangelhaft weiterentwickelt wird, weil es keine stabilen aktuellen Releases gibt, mühsam zu installieren ist, (problematische Programme wie MSYS enthält) und die Binaries offensichtlich unnötig groß sind (VC++ generiert wesentlich kleinere, auch wenn man die Standardlib statisch linkt)


Anmelden zum Antworten