MinGWs Zukunft?

volkard

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

abc.w

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

volkard

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.

abc.w

volkard schrieb:

abc.w schrieb:

bla blu furz

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

Ein Haufen von mir
Kann nicht sein

Artchi

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

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.

player424

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

Mr X

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)

player424

Nun gut da magst du recht haben. Als ich neulich die Wxwidgets samples kompilieren wollte, ist er bei einem Beispiel mit einem Segmentation fault abgeschmiert.
Ich denke aber der Compiler ist so beliebt, weil er etwas konkurrenzlos da steht. Ich meine sucht mal bei Google nach einem kostenlosen Kommandozeilencompiler. Alles worauf ihr stossen werdet ist der Borland 5.5, der leider etwas in die Jahre gekommen ist, oder die anderen Mitbewerber wie Watcom oder Digital Mars. Doch welche Bibliothek unterstützt diese Compiler schon? Höchstens der Watcom wird noch unterstützt aber der soll nicht so toll sein.
Und für Digital Mars hab ich noch bei keiner Bibliothek die ich mal benutzt habe entsprechende Makefiles gefunden (ausser wxwidgets ).

Zumindest das Problem mit der Installation kann man umgehen. Nämlich indem man den TDM-GCC Installer benutzt

Artchi

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?

Wer sich Windows-Compiler schimpft, sollte auch Windows-API unterstützen. Eigentlich eine ganz einfache Sache, oder?

Mr X

player424 schrieb:

Nun gut da magst du recht haben. Als ich neulich die Wxwidgets samples kompilieren wollte, ist er bei einem Beispiel mit einem Segmentation fault abgeschmiert.
Ich denke aber der Compiler ist so beliebt, weil er etwas konkurrenzlos da steht. Ich meine sucht mal bei Google nach einem kostenlosen Kommandozeilencompiler. Alles worauf ihr stossen werdet ist der Borland 5.5, der leider etwas in die Jahre gekommen ist, oder die anderen Mitbewerber wie Watcom oder Digital Mars. Doch welche Bibliothek unterstützt diese Compiler schon? Höchstens der Watcom wird noch unterstützt aber der soll nicht so toll sein.
Und für Digital Mars hab ich noch bei keiner Bibliothek die ich mal benutzt habe entsprechende Makefiles gefunden (ausser wxwidgets ).

Zumindest das Problem mit der Installation kann man umgehen. Nämlich indem man den TDM-GCC Installer benutzt

MSVC lässt sich auch über die Kommandozeile nutzen.

Zeus

Wieso nimmst du nicht den Visual C++ Compiler mitgeliefert bei jedem Windows SDK (IMO entspricht der Professional Version ohne PGO)?

player424

Das mag sein, aber man muss trotzdem die riesige IDE installieren

Zeus

Wieso? CodeBlocks arbeitet mit dem Compiler zusammen.

Mr X

Nein muss man nicht. Der Compiler ist im Windows SDK drin.

Dravere

player424 schrieb:

Das mag sein, aber man muss trotzdem die riesige IDE installieren

Siehe Antwort von Zeus & Mr X, zudem wurde auch schon weiter vorne erwähnt, dass man auch den Debugger kostenlos ohne IDE bekommt.

Zum MinGW, bzw. GCC auf Windows:
Was ist eigentlich mit dem Kompiler von TDM? Die haben auch x64 Unterstützung.
http://tdm-gcc.tdragon.net/

Dazu einen Installer für eine angenehme Installation. Sind allerdings halt auch von MinGW und MSYS abhängig, daher wohl in Sachen GDI+ nicht viel besser. Aber immerhin ist die Installation deutlich einfacher
Wenn ich den GCC auf Windows verwende, dann immer den von TDM.

Grüssli