MinGWs Zukunft?
-
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.
Vorerst werde ich Kompromisse eingehen. Wenn mein Projekt mehr Manpower hätte, könnte man evtl. per bedingter Kompilierung für den MinGW die GDI und für den MSC die GDI+ bzw. später Direct2d nutzen.
-
Zeus schrieb:
Anscheinend lässt Mingw nur noch die win32api durch Cygwin pflegen. Der Download und die Datei sind der Sorgeforge Seite und im SCM entfernt. Allerdings hat Cygwin GDI+ API vor einen Monat reingenommen. Außerdem ist es sehr bekannt wie gut Mingw ihre Release pflegen... eher garnicht. Also ich würde MinGW nicht supporten wollen.
Sieht ja echt übel aus. Fragt sich nur, warum alle so auf den MinGW fliegen? OK, als reiner C und C++ Compiler (also für Standard-Libs) ist er sicherlich brauchbar. Aber warum wird er z.B. im Code Blocks so favorisiert? Solche IDEs können doch problemlos das Windows SDK + MSC nutzen bzw. verweisen. Denn diese sind ja kostenlos von MS erhältlich.
-
Die Meinung scheint wohl zu sein, das man den MinGW nicht unterstützen muß. Werde ich wohl auch ab einem bestimmten Punkt in der Zukunft so handhaben.
Danke für Eure Meinung.
-
Artchi schrieb:
Zeus schrieb:
Anscheinend lässt Mingw nur noch die win32api durch Cygwin pflegen. Der Download und die Datei sind der Sorgeforge Seite und im SCM entfernt. Allerdings hat Cygwin GDI+ API vor einen Monat reingenommen. Außerdem ist es sehr bekannt wie gut Mingw ihre Release pflegen... eher garnicht. Also ich würde MinGW nicht supporten wollen.
Sieht ja echt übel aus. Fragt sich nur, warum alle so auf den MinGW fliegen? OK, als reiner C und C++ Compiler (also für Standard-Libs) ist er sicherlich brauchbar. Aber warum wird er z.B. im Code Blocks so favorisiert? Solche IDEs können doch problemlos das Windows SDK + MSC nutzen bzw. verweisen. Denn diese sind ja kostenlos von MS erhältlich.
Tja Code::Blocks kann ich mir nur so erklären als dass die IDE sehr gut geeignet ist um mit reinem C++ anzufangen, da es egal ist welches OS man nutzt. Die wxWidgets Unterstützung von CB ist auch nicht zu verachten. CB ist für mich ein Ersatz für das frühere DevC++ was ja in sehr vielen Artikeln und Büchern als Lehr-IDE bevorzugt wurde.
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.
-
Das läuft auf die Frage hinaus, wie verhält sich Microsoft den "Kleinkunden" gegenüber, wenn es keinen Wettbewerber mehr gibt?
Wird dann der Compiler und die API noch mit der notwendigen Ernsthaftigkeit weiterentwickelt, wenn keine Alternative da ist? War es nicht von es jahrelang von MS Usus die Mitbewerber mit "speziellen" Funktionen in ihren Programmen aus zu bremsen?
Und wird es dann, wenn Microsoft die alleinige Lösung ist, noch kostenfreie Programme für z.B. Studenten geben?
Kann ja sein das ich etwas missverstanden hab und Microsoft kein Wirtschaftsunternehmen, sonder ein charitativer Verein ist
Ich darf das noch schreiben, da ich nicht auf B.G.s oder seines Nachfolgers Gehaltsliste stehe
-
Es ist auch zusätzlicher Aufwand wenn man in einer IDE verschiedene Compiler (und vor allem Debugger) unterstützen will. Ich weiß auch grad gar nicht ob der Visual Studio Debugger im Plattform SDK vorhanden ist, und ob dieser eine dokumentierte Schnittstelle besitzt. Da ist das Arbeiten mit gdb evtl. einfacher.
-
hibbes schrieb:
Tja Code::Blocks kann ich mir nur so erklären als dass die IDE sehr gut geeignet ist um mit reinem C++ anzufangen, da es egal ist welches OS man nutzt. Die wxWidgets Unterstützung von CB ist auch nicht zu verachten. CB ist für mich ein Ersatz für das frühere DevC++ was ja in sehr vielen Artikeln und Büchern als Lehr-IDE bevorzugt wurde.
Der CB kann ja mit dem MSC umgehen. Das ist ja der Witz. Nur als Default ist halt MinGW eingestellt. Die brauchen bloß das Default ändern, und den Download-Link angeben, wenn man das Windows SDK noch nicht hat.
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.
-
Tobiking2 schrieb:
Es ist auch zusätzlicher Aufwand wenn man in einer IDE verschiedene Compiler (und vor allem Debugger) unterstützen will. Ich weiß auch grad gar nicht ob der Visual Studio Debugger im Plattform SDK vorhanden ist, und ob dieser eine dokumentierte Schnittstelle besitzt. Da ist das Arbeiten mit gdb evtl. einfacher.
Zum Debugger kann ich leider nichts sagen. Aber CB unterstützt von Haus aus auch den MSC mit Windows SDK.
-
Die Beliebheit von Mingw ist Geschichte als es kein freien Kompiler unter Windows gabs *gg*
-
f.-th. schrieb:
Das läuft auf die Frage hinaus, wie verhält sich Microsoft den "Kleinkunden" gegenüber, wenn es keinen Wettbewerber mehr gibt?
Wird dann der Compiler und die API noch mit der notwendigen Ernsthaftigkeit weiterentwickelt, wenn keine Alternative da ist? War es nicht von es jahrelang von MS Usus die Mitbewerber mit "speziellen" Funktionen in ihren Programmen aus zu bremsen?
Und wird es dann, wenn Microsoft die alleinige Lösung ist, noch kostenfreie Programme für z.B. Studenten geben?
Kann ja sein das ich etwas missverstanden hab und Microsoft kein Wirtschaftsunternehmen, sonder ein charitativer Verein ist
MS hat genug Konkurrenz auf Windows:
ICC (Intel C++ Compiler) http://software.intel.com/en-us/intel-parallel-composer/
PGI Compiler Tools http://www.pgroup.com/
Embarcadero Turbo C++ (ehem. Borland)Wobei der ICC der wohl bekannteste Konkurrent sein dürfte. Zumindest gibt es mehrere ernsthafte C++ Compiler für Windows. Den ICC kann man sogar von VisualStudio nahtlos aus benutzen.
Übrigens konnte man das Plattform SDK inkl. MSC schon vor 8 Jahren kostenlos runter laden. Ist also nicht erst seit heute so. Ob es vorher schon kostenlos war, weiß ich nicht, da ich da noch das VisualC++ 6 gekauft hatte.
-
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