Discussion :

[LittleWhite]

Bonjour à tous,

Avec les évolutions des normes du C et du C++, le choix du compilateur et même de sa version sont devenus un point important dans un projet de développement. Notamment, certains développeurs pouvaient être exaspérés du manque du support des dernières versions du C++ dans le compilateur de Microsoft, Visual C++. L'arrivée de Clang a apporté un renouveau dans le monde des compilateurs : l'équipe est très réactive pour implémenter les nouveautés du langage et sa modularité permet bien plus, et cela, plus facilement que GCC.

C'est pourquoi je souhaite vous poser cette question aujourd'hui. Quel est votre compilateur C/C++ préféré ? Avez-vous remplacé GCC par Clang ? Êtes-vous un inconditionnel de Visual C++ ? Utilisez-vous le compilateur d'Intel pour ses capacités d'optimisation ?


Nous avons la chance de pouvoir choisir entre plusieurs compilateurs. Tous sont bons et chacun possède ses avantages et ses inconvénients. Le choix n'est pas anodin lorsque nous savons que c'est l'outil qui générera le binaire final. Faites-vous des compromis dans votre choix ?


N'hésitez pas à nous dire en quoi vous aimez tel ou tel compilateur.



J'ai consciemment rassemblé le C et le C++ car les compilateurs C++ gèrent tout aussi bien le C.

[Max Lothaire]

GCC.
Je suis la plupart du temps sous linux, et ce compilateur par défaut fait le taf.

Si j'avais été sous Windows, j'aurais sans doute hésité. Est-ce que, mis-à-part qu'il soit libre, minGW a de réels avantages par rapport au compilateur de Microsoft ?

[Gugelhupf]

Je n'ai pas de compilateur préféré pour C++, je prends généralement celui qui est le moins prise de tête. Sous Windows, la dernière fois où j'ai fait du Qt je n'ai pas eu d'autre choix que d'utiliser MingGW.

[Aooka]

GCC car c'est le seul que j'ai pu essayer : pourquoi ? Car mes études me l'impose

[laerne]

On entend beaucoup parler de qualité des messages d'erreurs du compilateur de Microsoft.

Ben j'ai essayé visual studio, gcc et clang, et clang est vraiment plus clair dans la formulation des messages.

[Iradrille]

J'utilise principalement VC++, pas parce que c'est le meilleur ni mon préféré, mais c'est simplement un des seuls à s'intégrer à Visual Studio.

Si j'avais les moyens, j'utiliserais le compilo Intel : bon support de C++11 / C++14 et des perfs dans l'ensemble meilleures que VC++.

Avec Clang qui arrive sur Visual Studio, il est possible que j'abandonne VC++, tout dépendra du support de C++11 / C++14 / C++17 (et des perfs si la différence est grande) à ce moment là.

On entend beaucoup parler de qualité des messages d'erreurs du compilateur de Microsoft.

Ben j'ai essayé visual studio, gcc et clang, et clang est vraiment plus clair dans la formulation des messages.

Clang est le meilleur des trois au niveau des messages d'erreurs, c'est incontestable.
Maintenant avec l'habitude, n'importe quel compilo fourni des messages clairs. Même pas besoin de lire l'erreur, rien qu'en voyant la longueur de l'erreur on sait ce que c'est .

[Metalman]

Si j'avais été sous Windows, j'aurais sans doute hésité. Est-ce que, mis-à-part qu'il soit libre, minGW a de réels avantages par rapport au compilateur de Microsoft ?

Ca va paraitre très stupide, mais j'ai beaucoup galéré pour faire des applications "qui fonctionnent" chez mes amis en utilisant VS... alors que MinGW n'a jamais raté.
En effet, malgré les "redistributables VC/VC++" innombrables que j'ai fourni à des amis, j'étais incapable de faire fonctionner des exécutables simples chez tout le monde simultanément. (okok j'aurais dû aller dans la section C du forum pour le dire, mais à l'époque je ne connaissais pas vraiment dev.net ! )
Ca devait venir des libs utilisées, mais bref.
Pour faire des rushs jeux vidéos, MinGW reste un choix très bon sur Windows (et la gratuité aussi, pour vendre sur steam).


Perso j'utilise énormément GCC, un peu VS, et j'ai utilisé 2 ou 3 fois icc pour voir ce que cela produisait... mais icc gratuit n'optimise que pour pentium IV "de souvenir".

Pour compléter le sondage, il faudrait ajouter le compilo Sun/Oracle et les quelques extensions IBM comme le "Metal C" (nonon ce n'est pas une metalblague de metalman)

[born to code]

Jusque la j'utilise MinGw, mais je projette d'utiliser celui que propose visual c++ en guise de comparaison.

[captaindidou]

J'ai pleuré lorsque j'ai constaté que CUDA n'était pas compatible avec gcc sous windows alors que sous linux, si.

Je ne veux même pas entendre parler M$ C++. ça ne m'intéresse pas.

[renoo]

Mingw sous windows en 32 et 64 bits. J'utilise occasionnellement vs2015, j'aime bien l'idée de valider son code avec plusieurs compilateurs. Mais pour mon code, le binaire généré était 20% plus rapide avec gcc, j'ai pas trop chercher à comprendre en détail pourquoi peut être certains flags étaient mal réglés.
Je pense aussi que clang a mis un bon coup de pied pour faire avancer les choses et notamment les messages d'erreurs.

[azias]

Dans nos projets nous utilisons pour le moment gcc en cross-compilateur sur un linux (via jenkins) pour produire des exe windows 32bits de nos produits et aussi gcc (version mingw) sur nos PC pour le développement.

Mais je m'occupe progressivement de faire la transition vers msvc. Nous n'avons pas encore fait réellement de test de comparaison mais nos premiers essais qui nous ont amener à décider la transition ont montrés que les exe qu'on obtient sont plus petits et qu'ils sont plus rapide à l'éxécution (j'ai une différence d'au moins 30% sur un exe).

Depuis qu'il y a la version Community, nous pouvons envisager d'utiliser le compilo de Visual Studio (pas dans nos moyens sinon) et la disponiblité prochaine des outils de compilation utilisable sans installer Visual Studio est une très bonne nouvelle (nous utilons un serveur d'intégration continue et on n'a pas franchement envie d'installer tout Visual Studio sur un serveur).


Les difficultés/différences entre les deux que je rencontre sont:

• Différence de support du C++11 (aucun des deux ne prend en charge complètement la norme, et chacun le fait différemment)
• msvc plus strict sur certaines choses, par exemple il génère une erreur de compilation quand on veut affecter un littéral double à une variable float, ce qui n'est pas plus mal. Et d'une façon général aussi plus de warning sur les conversions implicites qui risquent de faire perdre de l'information.
• En revanche, nos tests unitaires (en utilisant cpputest) détectent des memory leaks avec msvc qui ne sont pas présents avec gcc, en l'occurence quand on utilise des stream (stringstream ou tout simplement sur des lecture/écriture de fichiers). Apparemment l'explication c'est que windows ne libère pas immédiatement les stream de façon synchrone, mais je me retrouve obligé de désactiver la détection des memory leaks sur les fonctions en questions pour les tests passent.
• gcc nécessite qu'on désactive certaines optimisations pour éviter certains plantages aléatoires (quand on utilise certaines fonction de Eigen), on n'a pas ce problème avec msvc.
• msvc est assez limitant concernant le link de bibliothèques qui ont pu être compilées avec des options différentes, ça évite sans doute des erreurs mais c'est assez strict.
  

En ce qui concerne les options de compilation, elles sont aussi compliquées à maîtriser chez l'un que chez l'autre, après il y a une question d'habitude sans doute. Pour les compilations nous nous basons sur CMake et un serveur d'intégration continue, donc une fois les choses configurées ça roule tout seul. Pour le développement, nous utilisons Eclipse, a priori msvc est aussi censé s'intégrer avec mais je n'ai pas encore testé plus que ça, en particulier il faut voir le debugger.

Sinon une chose qui pourrait s'avérer limitant c'est tout simplement la disponiblité de bibliothèques non open-sources dans les format supportés par le compilateur (msvc étant assez strict là-dessus il faut faire attention)

[Iradrille]

En ce qui concerne les options de compilation, elles sont aussi compliquées à maîtriser chez l'un que chez l'autre, après il y a une question d'habitude sans doute. Pour les compilations nous nous basons sur CMake et un serveur d'intégration continue, donc une fois les choses configurées ça roule tout seul. Pour le développement, nous utilisons Eclipse, a priori msvc est aussi censé s'intégrer avec mais je n'ai pas encore testé plus que ça, en particulier il faut voir le debugger.

Une bonne partie des options de compilations sont proche (typiquement "-x" pour GCC vs "/x" pour MSVC), mais oui c'est quelque chose à prendre en compte. Pareil pour les choses non portables / standard (inline assembly, forceinline, packing de structures, etc..).

Une autre différence qui m'a dérangé une fois pour le passage MSVC -> GCC est la différence au niveau du parsing des templates :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
template <class T>
void foo() {
	une grossiere erreur de syntaxe
}
 
int main() {
	return 0;
}

Ce code compile sur MSVC, pas sur GCC. La solution est simple : écrire du code correct et éviter le code mort. Mais sur le coup ça m'avait pas mal gêné .

[JPLAROCHE]

bonjour depuis plus de 16ans ont utilise GCC "mingw sous windows avec gestion de douchettes et AS400 + communication BD interne externe outil de gestions communicant en prise direct avec des Presses imprimerie " et GCC sous Linux site web et gestion entreprise NCURSE
la portabilité, la fiabilité, la documentation, les lib , le suivit des normes, les forums sur GCC ( hum MS est pas mal non plus).
j'ai essayé U++ mais trop solitaire et propriétaire (peut être ils auraient du allez plus loin ).
VC trop de propriétaire. ****** GCC multiplate-forme.
j'allais vous marqué les réglages du compilateur GCC mais ont peut avec quelques efforts aussi bien réglé avec MS
@bientôt

[laubea]

tout est dans le titre non?...what else ?
apprendre a se servir d'un outil demande du temps, quand j'en aurais j'essaierais un autre outil, mais pour le moment ce que je lui demande Visual le fait tres bien.

[TJ1985]

Je suis un débutant en C++, ou plutôt j'ai fait pas mal de maintenance sur du code existant un peu à l'arrache et maintenant je m'intéresse à en prendre une bonne maîtrise. Dans ce contexte je travaille sous OSX et Linux, dans ces deux environnements Clang me semble faire un excellent boulot. Bref, c'est une option dont je suis satisfait.

[SDN87]

pour ma part, je ne suis pas un développeur aguerri en c++, je m'efforce encore de l'apprendre tout seul. mais ce qui m'a dérouté plus d'une fois c'est le support de certaines bibliothèque. certaines bibliothèque serait compatible avec gcc et pas avec msvc... et c'est parfois l'un de mes critère de choix lorsque je dois me lancer à fond dans un projet. mais parfois la question que je me pose c'est de savoir si c'est la bonne solution se choisir son compilateur par la disponibilité des bibliothèques. encore que lorsque on devrait intégrer plusieurs bibliothèque je me rends compte qu'il faudrait plusieurs compilateur (chacun pour sa bibliothèque). très déroutant parfois

[ChristianRoberge]

Nous utilisons gcc et msvc. Visual est nettement plus efficace pour le débogage et il construit de meilleurs codes et plus rapide. Le problème de msvc est son retard chronique sur les normes C++. Depuis le dernier update de Visual 2015, clang est aussi offert sous Visual. Nous envisageons d'unifier nos compilateur en délaissant gcc au profit de clang sous Linux.

[RFManu]

Il me semble que le compilateur C++ builder (Embarcadero), nommé BCC32 ou BCC64 devrait être dans la liste? C'est personnellement le seul que j'utilise est il fonctionne vraiment pas mal, en 32 comme en 64bits.
Bonne journée.

[foetus]

Il me semble que le compilateur C++ builder (Embarcadero), nommé BCC32 ou BCC64 devrait être dans la liste?

C'est une grosse m*rd*

Dans les points douteux:

• Il a tout un tas d'extensions pour l'IDE: __closure, __published, __property, ... Et par exemple __closure permet de faire des pointeurs de fonctions en prenant directement l'adresse (le déplacement plus exactement) de la méthode dans le bon objet. Ce qui est illégal en C++.
• Il ne reconnait pas le format COFF pour les bibliothèques statiques (OMF format). Et c'est le seul.
• Il compile par défaut en préfixant tout avec des tirets bas. Mais lorsqu'on essaye d'intégrer une bibliothèque externe en statique, qui elle, a fait un truc classique, c'est la prise de chou.
• La gestion des types énumérés (et sûrement aussi avec les classes mais pas testé) à l'intérieur des classes est une gageure. Il faut les mettre en premier et partout forcer la définition "ClassXX::Type" sinon le compilateur n'arrive pas utiliser ton type.
• Pour compiler en statique c'est également mystérieux. Il y a 2 options à décocher "Link with dynamic RTL" et "Build with runtime packages"
• Il y aussi tous les trucs bizarres comme #pragma hdrstop, #pragma package(smart_init), la gestion des fichiers .DFU pour l'IDE et les fameux #pragma link et #pragma resource les seules options pour intégrer des bibliothèques ou ressources à ton projet.

Et personne sauf les intéressés ne savent d'où vient ce compilateur

Un truc de bien: on peut choisir le type (char, short, ...) du type énuméré. Mais c'est une nouvelle fonctionnalité du C+11.