MinGW 4.7 ou Visual C++ 11(2012)

Bonjour,

je commence un nouveau projet et je souhaite partir sur des outils à jour.

Je développe uniquement sur Windows. Seulement j'hésite à choisir mon compilateur

Je compte utilisé aussi Qt 5.0.2 (qui aura des binaires Vs 2012 ET MinGW 4.7)
Et, peut-être boost

Donc, j'hésite entre MinGW 4.7 ou Visual C++ 11 (Visual Studio 2012)

QUID performance, compatibilité windows de MinGW ?

Merci d'avance pour vos commentaires

Pour le reste je ne peux pas te répondre, mais pour le C++11 MinGW est clairement plus fourni. Je n'ai pas eu de problèmes de performances avec MinGW, mais je n'ai pas vraiment d'élément de comparaison.

Hello,

Visual Studio est un excellent IDE et probablement le meilleur sous Windows (après les goûts et les couleurs ... :)). Le debugger de VS est aussi un cran au dessus de gdb.
L'utilisation de MinGW avec VS n'est vraiment pas simple (même pas sur que se soit possible ?).

Le seul problème de VS est le faible support de C++11 actuellement, mais si c'est un projet perso, le CTP de novembre ajoute pas mal de fonctionnalités (vu que c'est une preview, vaut mieux éviter pour un projet pro).

MinGW n'a pas de problèmes de compatibilités avec Windows (à part Ogre, il me semble).
Niveau performance, pas de soucis non plus.

Au final, à toi de juger si le faible support de C++11 est plus ou moins important que la qualité de l'IDE (encore une fois, c'est subjectif, VS on l'aime ou on l'aime pas).

Quel rapport avec l'IDE ? Je peux très compiler mon application Visual C++ 11 avec QtCreator, ou C::B

Quand on parle de VS, on parle souvent de l'IDE complet, pas du compilateur. Et sans précision, on parle aussi souvent de la version non Express (il y a du coup parfois des incompréhensions dans les discussions...)

Donc si c'est que le compilateur qui t'intéresse, VSC++ Express convient et les arguments sur l'IDE n'ont pas d'intérêt
Les autres remarques de Iradrille sur le débogueur et la compatibilité de mingw restent valables.

Tu as un tableau relativement à jour sur la comparaison du support du C++11 là : http://wiki.apache.org/stdcxx/C%2B%2B0xCompilerSupport (mise à jour en décembre)

Petite remarque concernant la portabilité : le langage est portable (= supporté correctement par plusieurs compilateurs sur plusieurs plateformes), Qt est portable, boost est portable. Bref, tout est portable.
Alors même si tu bosses que sur Windows, écris du code portable quand même (sauf si tu fais de la programmation système ou autre truc tordu)

Tu peux également t'amuser à tester gcc 4.8, qui améliore encore plus le support du C++11, tu peux trouver les binaires là : http://www.equation.com/servlet/equation.cmd?fa=fortran

MinGW EST un compilateur pour Windows. La question de la compatibilité ne se pose pas. Dès lors que du code n'utilise pas des extensions spécifiques à VS (et encore... certaines ont été implémentées), alors le code peut être compilé par MinGW.

Un article datant de l'année dernière donne une vision des performances relatives de VC++ 2010 et MinGW. D'après les graphes obtenus par hardware.fr, il y a une différence de l'ordre de 5% entre cl (Visual C++) et MingGW - ce qui est somme toute correct. Dans certains cas, le rapport de force est inversé (MinGW produit un exe plus rapide que cl) et dans d'autres, la différence est plus importante (cl peut générer du code 10, 15% plus rapide que MinGW).

Ceci dit, tu veux faire du Qt. Donc, à priori, du code de gestion d'une interface graphique. Tu vas passer plus de temps à attendre les ordre de l'utilisateur (souris, clavier) qu'à faire des choses qui nécessite des performances vraiment poussées. Du coup, un gain de 5% ne sera pas vraiment des plus intéressants...

Au niveau du support C++11, il vaut mieux utiliser g++ - sauf que certains points très importants manquent encore (std::regex, move ctor sur les stream de la librairie standard, ...). D'un autre coté, le dernier CTP rajoute pas mal de petites choses qui le rapprochent de g++ en la matière. En fait, il faudra que tu vérifies le corpus de fonctionnalités dont tu auras besoin - et là tu pourras faire ton choix.

On a le droit de jouer avec les mots ?
MinGW n'est pas un compilateur C++. C'est g++ le compilateur. :lol:

Sinon j'appuie les dires d'Emmanuel Deloget :ccool:

Citation:

---

Envoyé par nostrora

Quel rapport avec l'IDE ? Je peux très compiler mon application Visual C++ 11 avec QtCreator, ou C::B

---

Oui bien sur, mais la principale valeur ajoutée de VS est l'IDE qui vient avec.

Hello,

contrairement à VC++, minGW ne supporte pas les threads de C++11. Si tu en as besoin, il faudra passer par boost::thread ou Qthread.

Si, mingw prend en charge les threads. La seule chose (sans importance pour l'utilisateur), c'est que c'est un wrapper sur d'autres libs de threads (pthread sur linux, les threads système sur windows)

Mais il y a d'autres choses que mingw ne gère pas directement, comme les regex

Citation:

---

Envoyé par gbdivers

Si, mingw prend en charge les threads. La seule chose (sans importance pour l'utilisateur), c'est que c'est un wrapper sur d'autres libs de threads (pthread sur linux, les threads système sur windows)

Mais il y a d'autres choses que mingw ne gère pas directement, comme les regex

---

Ah... j'avais pourtant essayé (avec 4.6.3 me semble-t-il)
et le code

Code:

---

std::thread::hardware_concurrency()

---

me renvoyait inlassablement 0

Peut être faut-il faire un build spécifique ?

J'avais essayé aussi avec mingw 0.1.5 alpha, ça marchait pas non plus... :)

Je saurais pas dire de quand date l'ajout, il faut regarder dans la doc de gcc, probablement que cela date de 4.7.

Sinon, deux autres tableaux comparatifs, qui contient en particulier la comparaison de la STL : http://cpprocks.com/c11-compiler-sup...c-clang-intel/
GCC a un peu de retard sur VS et Cling pour la STL, par contre, elle se rattrape largement sur le support du langage

Citation:

---

Envoyé par gbdivers

J'avais essayé aussi avec mingw 0.1.5 alpha, ça marchait pas non plus... :)

---

En fait non ça ne renvoyait pas 0, ça ne compilait pas. Et là j'ai essayé avec 4.7.2 (qui est relativement récent) et idem

Code:

---

1 2 3 4 5 6 7 8 9

C:\MinGW\bin>"mingw32-c++.exe" -v Utilisation des specs internes. COLLECT_GCC=mingw32-c++.exe COLLECT_LTO_WRAPPER=c:/mingw/bin/../libexec/gcc/mingw32/4.7.2/lto-wrapper.exe Target: mingw32 Configuré avec: ../gcc-4.7.2/configure --enable-languages=c,c++,ada,fortran,objc,obj-c++ --disable-sjlj-exceptions --with-dwarf2 --enable-shared --enable-libgomp --disable-win32-registry --enable-libs tdcxx-debug --disable-build-poststage1-with-cxx --enable-version-specific-runtime-libs --build=mingw32 --prefix=/mingw Modèle de thread: win32 gcc version 4.7.2 (GCC)

---

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

#include <iostream> #include <thread> #include <boost/thread.hpp>   int main(int argc, char *argv[]) {   std::cout << "C++ vesrion: " << __cplusplus << std::endl;   std::cout << "Std hardware concurrency: " << std::thread::hardware_concurrency() << std::endl;   std::cout << "Boost hardware concurrency: " << boost::thread::hardware_concurrency() << std::endl;   return 0; }

---

La compilation échoue lamentablement avec

Code:

---

..\sources\main.cpp:10:51: error: 'std::thread' has not been declared

---

en mettant la ligne 10 en commentaire:

Code:

---

1 2	C++ vesrion: 201103 Boost hardware concurrency: 4

---

EDIT: peut-être y a-t-il des builds custom de minGW pour lesquels ça marche. Moi j'ai pris la version standard sur http://www.mingw.org/

Chez moi ça compile, avec la même version de mingw :koi:

Tu compiles comment ? (options de compilation)

EDIT : j'utilise la version fournit avec Qt, c'est la version standard aussi

à noter pour la défense de g++ sur sa stdlibc++ par rapport à libc++ de clang (et non pas cling) c'est que libc++ n'est complète que pour Mac OS X...
En espérant que les prochaines versions des deux lib amènent un plus grand support, voire (on a le droit de rêver :D) un support complet sur les 3 plateformes...

Et la version standard de MinGW n'est pas la dernière, c'est la 4.6 et quelques. Il y a un bouton à cocher pour obtenir la dernière pendant l'installation.

Code:

---

1 2 3 4

g++ -c -std=gnu++11 -DBOOST_THREAD_USE_LIB -D_WIN32_WINNT=0x0601 -g -frtti -fexceptions -mthreads -Wall -DUNICODE -DQT_LARGEFILE_SUPPORT -D_DEBUG -I"..\..\..\boost" -I"..\project" -I"." -I"..\..\..\QtSDK\Desktop\Qt\4.8.0\mingw\mkspecs\win32-g++" -o debug\main.o ..\sources\main.cpp

---

Perso, j'aime pas les regex et je sais pas trop ce que sont les "Concurrency: relaxed memory ordering and fences", donc pour moi, l'un ou l'autre, c'est pareil
Par contre, il faudrait que j'aille voir à quoi correspond exactement ce support partiel de type trait

Niveau langage, entre gcc et Clang, il n'y a que le manque des constructeurs délégés dans Clang qui me gène. Dans VS, il y a encore trop de manque pour moi (alias template, delete, default, constexpr, initialisation des membres non static, noexcept, qui sont pour moi des fonctionnalités utilisables "dans la vie de tous les jours")

Sinon, je crois pas que gcc a besoin d'être défendu :)
Mais s'il le fallait quand même, je dirais qu'un gros boulot de gcc 4.8 a été le passage au C++. Maintenant que c'est fait, on aura probablement plus de nouvelles fonctionnalités implémentées (en particulier les propositions du C++1y ?)

Ah oui tiens, c'est vrai que gcc est passé au C++...
Pour les proposals ça me fait penser que y'en a une floppée qui sont sortis ces jour-ci, dont certains très intéressant !

Des proposales du comité ? Je crois pas (ou alors tu parles de la préparation de la prochaine conf, les drafts ont été publiés... mais mieux veut lire les drafts après la conf :))
J'ai vu qu'il était passé à 10 SG (j'étais resté à 8 dans ma mémoire je crois)


@GeantVert13
Bon, tu utilises aussi Qt :) (par contre, faudrait passer à Qt 5. Ou au moins à une version plus récente que Qt 4.8.0 ;))

Mes options :

Code:

---

1 2 3 4

g++ -c -std=c++11 -g -frtti -Wall -Wextra -fexceptions -mthreads -DUNICODE -DQT_QML_DEBUG -DQT_DECLARATIVE_DEBUG -I..\test-thread -I"." -I"..\..\..\..\Qt\Qt5.0.1\5.0.1\mingw47_32\mkspecs\win32-g++" -o debug\main.o ..\test-thread\main.cpp

---

A part les options pour boost, je vois pas trop

C'est quoi "-D_WIN32_WINNT=0x0601 " ?

Je sais pas à quoi ils se rapportent, je parle de N3526 N3536 N3531 N3535 N3538, ainsi que les minutes des récentes téléconférences qui portent sur les concepts et transactional memory...

Je confond, la dernière publication n'est pas une préparation pour un meeting mais les rapports des WG a priori : http://www.open-std.org/jtc1/sc22/wg21/docs/papers/ (au contraire des précédents qui étaient des rapports des SG)
Si tu parles des N sur isocpp, ça doit être des modifs des drafts suite aux réunions téléphonique

Je suppose qu'il y a eu une remontrer des drafts des SG dans les WG suite à Portland, une publication des propositions des WG pour le comité et que c'est reparti vers les SG pour complément
Quelqu'un à la téléphone de Stroustrup sous la main pour lui demander si je me plante ?

salut tout le monde,

Citation:

---

Envoyé par gbdivers

C'est quoi "-D_WIN32_WINNT=0x0601 " ?

---

c'est pour définir l'os minimum cible à supporter, voir msdn mais moi je préfère mettre ça dans les sources directement.

sinon pour gcc, enfin son pendant windows qu'est mingw, je le trouve tout simplement extra surtout depuis les apports C++11, la seule limitation c'est sa partie win32api qui parfois peu poser problème parce que telle ou telle api n'est pas "implémentée" ou ne l'est que partiellement, dans quel cas on doit y remédier et ça peut devenir vite rébarbatif...

J'ai testé en ajoutant cette option, mais ça compile et s'exécute quand même

win32 ? Il y en a qui programme encore avec ça ?

Oui, Laurent :mrgreen:

Citation:

---

ça compile et s'exécute quand même

---

T'as une erreur à la compilation seulement si dans ton code tu tentes l'utilisation d'une api ou fonction qui n'est pas disponible sur l'os que tu cibles, sinon c'est transparent comme tu peux le constater avec cet extrait de l'entête COMMCTRL:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

#if (_WIN32_WINNT >= 0x0501) typedef LRESULT (CALLBACK *SUBCLASSPROC)(HWND,UINT,WPARAM,LPARAM,UINT_PTR,DWORD_PTR); typedef struct tagLITEM { UINT mask; int iLink; UINT state; UINT stateMask; WCHAR szID[MAX_LINKID_TEXT]; WCHAR szUrl[L_MAX_URL_LENGTH]; } LITEM,*PLITEM; typedef struct tagLHITTESTINFO { POINT pt; LITEM item; } LHITTESTINFO,*PLHITTESTINFO; typedef struct tagNMLINK { NMHDR hdr; LITEM item; } NMLINK,*PNMLINK; #endif /* _WIN32_WINNT >= 0x0501 */

---

En ce qui concerne win32 c'est très simple, tous les frameworks que tu connais n'en sont que des wrappers, la seule variante si je puis dire c'est la part qu'elle représente dans le framework et la portion de l'api wrapper, mais aucun ne saurait s'en passer, enfin ceux qui permettent de faire des applications, on s'entend...

Citation:

---

Envoyé par gbdivers

J'ai testé en ajoutant cette option, mais ça compile et s'exécute quand même?

---

Bon ben je sais pas trop... du coup j'ai laissé tombé MinGW. J'utilise MSVC 2012 (avec le CTP nov 2012) sous windows et j'ai installé une VM ubuntu 12.10 pour gcc et j'essaye de faire un code qui compile des 2 cotés

Bonjour,

Pour rappel, voici les fonctionnalités C++11 gérés par chacun des compilateurs : http://www.ozone3d.net/public/jegx/2...2012_clang.jpg et juste pour cela, je serai tenté de conseiller un compilateur comme G++ ou CLang.

Salut,

A titre personnel, je préfères malgré tout Gcc ou Clang à VC++

Ce n'est, bien sur, qu'un avis strictement personnel, mais, outre les fonctionnalités vraiment intéressantes que mes deux préférés proposent et que l'on attend encore de la part de VC++, je trouve qu'ils proposent aussi de nombreux avertissements utiles et intéressants qui n'apparaissent pas avec VC++.

Déjà, je ne suis pas fan de cette manie qu'a microsoft de nous sortir un avertissement nous conseillant d'utiliser sa version "sécurisée" (mais totalement personnelle) de certaines fonctions "standard" (même si c'est, a priori, plutôt posix que ANSI), mais, en plus, je trouve que son compilateur laisse beaucoup trop allègrement passer certains comportements qui risquent réellement d'avoir des conséquences catastrophiques.

Comprenons nous bien, je ne prétend absolument pas que les avertissements soient forcément simples à comprendre (quoi que ceux auxquels je pense soient plutôt explicites), mais, qu'il s'agit, simplement, d'avertissements qui, si on veille à les prendre en compte, permettent d'éviter de nombreux comportements indéfinis et, par là même, de nombreux problèmes à l'exécution dont l'origine peut etre vraiment difficile à dénicher.

Alors, bien sur, gagner de 5 à 15 % en terme de performances peut s'avérer intéressant, mais, où se trouve l'intérêt de gagner en performance et de se retrouver au final avec une application qui plante purement et simplement parce qu'on a oublié d'initialiser une variable quelconque ou pour toute autre raison sur laquelle le compilateur aurait du attirer notre attention sur le fait que nous faisions quelque chose de risqué :question:

Peut etre ne serez vous pas d'accord avec mon point de vue, mais, personnellement, j'estime que la première chose que l'on doit demander à une application est de faire correctement ce qu'on lui demande, et de le faire sans risquer de planter.

Le problème de performances ne devrait, a mon sens, n'être abordé qu'à partir du moment où ce pré requis à mon sens indispensable est atteint, non :question:

Je suis parfaitement d'accord.
Ce qui fait qu'éventuellement, je compile avec plusieurs compilateurs, pour avoir plusieurs "avis", et prendre le binaire présentant les meilleurs performances une fois la sûreté obtenue sur tous.