Discussion :

[flamme34]

Bonjour

Je souhaites me mettre à la programmation c++ en 64 bits.
J'aurais besoin d'aide pour choisir l'IDE et le compilateur.

J'ai déjà fais quelques recherche et ai trouvé : code::block, Qt, Dev c++, visual studio, Ultimate ++ en terme d'IDE, et msvc 64 bits , mingw64, gcc en terme de compilateur.

Quels sont les inconvénients et les avantages de chacun ?
Si il y en a que je n'ai pas cité pareil.

Merci d'avance pour vos conseils.

EDIT : Je suis sous Windows ( win 7) et en 32 bits j'utilisais Borland c++ 6.0

[ternel]

oublie dev-c++, il est périmé.

[flamme34]

c'est noté pour Dev c++, et pour les autres?

[ternel]

Pour ce que j'en sais:
QtBuilder est recommandé pour écrire des applications utilisant Qt.

code::block est un classique, tu auras de l'aide à volonté sur internet.
Visual studio repose sur le compilo microsoft, avec toutes ses spécificités. C'est une bonne chose pour des applications dédiées à windows. Comme EDI, il est pas mal (quoi qu'assez lourd à mon goût).
Je ne connais pas Ultimate ++
Il y a aussi Eclipse Cdt, qui a le défaut d'Eclipse: un peu lourd et lent.

msvc est orienté pour windows, je ne crois pas qu'il soit vraiment capable de cross compiler vers linux.
mingw64 + gcc sera utilisable par code::blocks. Se baser sur gcc me semble un plus pour la portabilité vers les linux.

Personnellement, je me tournerai vers code::blocks + mingw64 + gcc, pour des raisons de portabilité.
Si tu veux faire des applications "à taille humaine", il y a une autre possibilité: utiliser notepad++ comme éditeur, et mingw64 + gcc pour la compilation.

[dragonjoker59]

Même si tu veux faire du code cross platform, si tu es sous Windows pour l'édition je te conseille VisualStudio, qui est à mon goût le meilleur IDE (je n'ai cependant pas testé Les derniers Borlands mais ils n'ont pas de version gratuite).
Pour la compilation, MSVC sous Windows est un bon choix ne serait-ce que pour valider une première fois le code. Le passer sous GCC ou Clang est à faire de toute façon si on veut faire du cross platform.
Je te conseille pour ne pas avoir trop de soucis à gérer les projets, makefile et autres d'utiliser CMake qui permet de générer ces fichiers. Tu pourras de plus spécifier que tu veux une compilation 64 bits en fonction du compilateur (genre -m64 pour GCC).

[r0d]

Et puis c'est vrai que si le trio C::B + mingwin + gcc a de nombreux avantages, pour débutant ça peut être un peu compliqué. Une version gratuite de VS est vite installée, le premier projet est créé en 10 secondes, et il peut ainsi commencer à coder tout de suite. Mais VS ne fonctionne que sous (et ne génère que du code pour) Windows.

[flamme34]

mes programmes ne sont destiné à tourner que sur Windows.

[Niark13]

Je te conseille Visual Studio Express, la version gratuite de VS qui dans sa version 2012 dispose d'un compilateur 64bits.

[Neckara]

Bonjour,

Pour l'IDE, je te conseillerais chaudement QtCreator qui est très simple d'utilisation et qui te permettra de faire du Qt sans changer de compilateur, de plus QtCreator est assez pratique quand on développe sur plusieurs OS grâce à ses fichiers de projets.
J'ai aussi utilisé Code::Block, je ne l'avais pas trouvé si compliqué que cela mais je préfère largement QtCreator
Pour Visual Studio, je l'ai utilisé en TP et j'en ai gardé une assez mauvaise expérience, il faillait faire attention de ne pas mettre la souris tout à gauche sous peine de geler l'application 5 minutes le temps de charger la boîte d'outils. Ensuite je ne sais pas si VS te permet de changer de compilateur (?), je n'ai jamais essayé de le faire.

Après, c'est plus une question de goûts et de couleurs.

Au niveau compilateur, je te déconseille celui de VS, personnellement je pense qu'aucun programmeur un minimum avertit ne devrait utiliser un compilateur dont on ne soit pas sûr qu'il respecte et respectera correctement les normes.
Donc je recommanderais plutôt gcc ou mingw.

Ensuite, même si tes applications ne tourneront que sur Windows, je te recommande de faire du code portable (sauf cas très spécifique) pour les raisons suivantes :
- ça ne coûte rien ;
- le jour où tu veux réutiliser tes sources sur Linux ou sur Mac, tu ne seras pas bloqué ;
- un utilisateur pourra ainsi porter ton application sur Linux et te faire gagner un public plus large ;
- si tu veux faire un serveur, cela pourra t'éviter de devoir prendre un serveur Windows

[ternel]

Un dernier avantage au code portable.

Si tu as un soucis, tu pourras venir nous demander de l'aide, nous pourrons tous t'aider.

[koala01]

Salut,

De manière générale, il faut déjà sans doute faire la différence entre l'EDI (qui n'est jamais qu'un programme qui regroupe "tout ce qui va bien" pour faire du développement) et... ce que l'on pourrait appeler la "chaine de compilation", c'est à dire "tous les outils qui seront utilisés pour transformer du code source en exécutable".

L'EDI (Environnement de Developpement Intégré) en lui même peut parfaitement ne pas être "64 bits compliant", si la chaine de compilation est prévue pour générer par défaut des exécutables 64 bits, tu auras des exécutables 64 bits.

Tu as généralement deux possibilités concernant la chaine de compilation:
Soit elle n'est prévue pour pouvoir ne fournir que des exécutables adaptés à une architecture particulière (32 bits ou 64 bits), soit, elle est prévue pour pouvoir fournir des exécutables pour les deux architectures.

Il est alors possible de générer des exécutables pour "l'autre architecture" en passant une option de compilation particulière ( -m32 ou -m64 avec Gcc par exemple).

Une petite remarque, en passant, concernant MinGW, MinGW-w64 et Gcc:

Les deux premiers ne sont que des portages du dernier sous windows.

C'est à dire que Gcc a, a l'origine, pas été prévu pour fonctionner sous windows car il utilisait assez massivement les en-tête et les bibliothèques "unix like".

MinGW et MinGW-w64 ne sont que des projets qui permettent de faire en sorte que Gcc fonctionne correctement sous windows, et n'apporte que "ce qui est nécessaire" pour ce faire (les fichiers d'en-têtes propres à windows et la "transcription" des bibliothèques de base).

La différence entre MinGW et MinGW-w64 est que le premier est un projet plus ancien qui date de bien avant que l'on n'ait l'intention de fournir des pc en version 64 bits, alors que MinGW-w64 rajoute le support du 64 bits.

Mais les deux projets sont basés sur Gcc, et il m'arrive, par exemple, régulièrement de compiler la version de développement de Gcc avec MinGW-w64 (en fait, MinGW est l'abréviation de Minimal Gcc for Windows )

En outre, je ne peux pas m'empêcher de réagir à des phrases comme:

mes programmes ne sont destiné à tourner que sur Windows.

ou comme

Un dernier avantage au code portable.

Si tu as un soucis, tu pourras venir nous demander de l'aide, nous pourrons tous t'aider.

D'abord, oui, tes applications vont sans doute être "orientées vers windows" au début, mais tu ne peux jamais savoir si tu n'auras pas, à un moment ou à un autre, "l'idée farfelue" de faire en sorte que ton application puisse aussi être compilée sous linux ou sous mac.

Concernant le code portable: oui, bien sur, l'idéal reste de créer du code portable en toutes circonstances. Mais ce n'est malgré tout pas parce que tu vas compiler ton code avec VC++ que ton code ne sera pas portable!

Ce qu'il faut, surtout, c'est veiller à ne pas utiliser d'extension propre à une chaine d'outils (en gros, éviter comme la peste tout ce qui est préfixé de _ ou de __, même si c'est accessible, et même si l'intellisens les fait apparaitre )

Il faut, cependant, avouer que Visual Studio est "à la traine" par rapport aux autres compilateurs en terme de respect du dernier standard.

Outre la lourdeur de l'EDI (malgré ses qualités intrinsèques), c'est sans doute le principal reproche que l'on peut faire à VS.

Pensez que Clang existe dans une version qui supporte entièrement C++11... Même si c'est tout récent, ca laisse songeur, non

Ca, c'était pour le seul aspect de la chaine de compilation.

Concernant les IDE (Integrated Development Environment), maintenant.

On écarte, comme cela a été dit, directement Dev-C++ car, bien que ca ait été un excellent IDE, il n'est plus maintenu depuis plusieurs années, et qu'il est donc tout à fait obsolète.

Qt n'est pas, à la base, un EDI, mais une bibliothèque destinée, à la base, à créer des applications graphiques et elle vient avec une série d'outils qui lui sont propres, mais j'en reparlerai un peu plus tard

L'énorme avantage de Code::Blocks, c'est qu'il s'agit d'un IDE particulièrement léger, qui peut sans aucun problème utiliser différents compilateurs.

Comme il est, de plus, tout à fait capable de travailler avec de Makefile, et, ce qui ne gâche rien, disponible pour différents OS, c'est sans doute un "maitre choix" pour débuter

Visual Studio, ben, ces microsoft, avec tout ce que cela comporte: une version "bridée" (visual studio express) qui est gratuite gratuite, les autres sont à des prix qui les rendent inaccessibles si l'idée est juste de "s'amuser" à développer des choses à but privé

L'IDE est bon, bien conçu et intègre parfaitement l'aide et les différents outils mais excessivement lourd et parfois un peu lent.

Outre son poids excessif, on pourrait considérer comme un défaut le fait qu'il ne puisse fonctionner qu'avec... la chaine d'outils de microsoft, mais il ne faut pas s'en étonner outre mesure

J'ai toujours eu un "problème philosophique" à l'idée de devoir installer java pour pouvoir compiler du C++, et donc cela fausse énormément mon avis concernant Eclipse.

Je reconnait qu'il s'agit d'un IDE correct, mais il est aussi parfois un peu lent

Je ne connait pas Ultimate++ et n'émettrai donc aucun avis à ce sujet

Mais revenons un peu à Qt qui a été cité dans la discussion.

Il me semble opportun de faire clairement la distinction entre son role de bibliothèque et l'EDI qu'elle propose (QtCreator).

Je ne suis pas loin d'estimer que si tu décides de créer une application graphique, c'est, très clairement la bibliothèque que je te conseillerais parce qu'elle est "assez bien foutue" d'une part, et qu'elle est développée dans un soucis de portabilité d'autre part.

Du coup, à moins de vouloir utiliser les activeX (qui n'existent que sous windows), il y a de fortes chances que les applications qui utilisent Qt puissent être compilées aussi bien sous windows que sous unix like sans nécessiter de modification importante.

De plus, il est tout à fait possible d'utiliser Qt en conjonction avec Code::Blocks, Eclipse et Visual Studio (même si c'est plus facile avec VS pro )

Quant à son IDE (QtCreator), il est malgré tout, quoi qu'on puisse en dire, assez efficace et permet de travailler facilement (en plus, il reste malgré tout léger ), et ce avec différents compilateur (très certainement VC++ et Gcc like )

Enfin, il y a un dernier "problème" qui est commun à la plupart de IDE et qu'il faut, peut etre, envisager de prendre en compte.

C'est le fait que quasiment tous utilisent leur propre format pour la gestion de projet / de solution, même si certains peuvent travailler plus ou moins correctement avec des Makefile.

Il ne faut pas oublier qu'un IDE n'est jamais qu'un ensemble d'outils "qui vont bien ensemble":

• un éditeur de texte qui permet l'auto complétion et la coloration syntaxique
• un système de gestion de "solutions" et de projets
• une chaine de compilation complète
• un système de compilation automatique
• un débuggeur que l'on peut utiliser de manière intégrée
• des fichiers d'aide plus ou moins fournis et plus ou moins accessibles

A partir du moment où tu disposes d'une chaine de compilation complète, d'un débuggeur, et d'un système de compilation automatique, tu peux presque estimer que les seules choses qui te manqueraient peut etre, sont l'auto complétion et la coloration syntaxique

De nombreux éditeurs de texte sont capables de te les fournir (je pense entre autres à notepad++ )

Si tu veux "commencer simple et léger", tu peux aussi envisager de travailler simplement avec de makefile, la ligne de commande et un tel éditeur de texte

Voilà, je crois que j'ai fait le tour, même si j'ai souvent donné des avis personnels

[r0d]

Voilà, je crois que j'ai fait le tour, même si j'ai souvent donné des avis personnels

Avis que je partage en tout points.

[stardeath]

il y a de bons avis mais je souhaite tempérer le "code portable", outre le fait que ça a un coût (ben oui, c'est bien gentil de croire qu'on programme portable, si on ne teste pas réellement, ce n'est que supposition), c'est surtout se mettre des contraintes inutiles, et surtout les mettre avant d'autres problématiques plus importantes selon moi :

- faire du code qui déjà fonctionne (gaffe au code qui tombe en marche)
- faire du code fonctionnant tant en 32 qu'en 64 bits (facile de tomber dans le piège)
- ne pas ré-inventer la roue, utiliser la stl
- ne pas forcément non plus embarquer une bibliothèque qui ne fera qu'alourdir l'exe final (qui a dit qt?)

[koala01]

il y a de bons avis mais je souhaite tempérer le "code portable", outre le fait que ça a un coût (ben oui, c'est bien gentil de croire qu'on programme portable, si on ne teste pas réellement, ce n'est que supposition), c'est surtout se mettre des contraintes inutiles, et surtout les mettre avant d'autres problématiques plus importantes selon moi :

Hé bien, je n'en suis pas si sur...

A la limite près que l'on est, parfois, limité par le support de la norme par le compilateur (je n'en reviens par exemple toujours pas que VS2012 ne supporte pas les fonctions marquées delete !!!), si tu respecte la norme, ton code sera vraisemblablement portable.

Les points de variations éventuels sont, justement, dus au fait que certains compilateurs ont mis l'accent sur certaines nouvelles fonctionnalités qu'ils ont préféré implémenter avant d'autre, et que chaque équipe de développement a pu trouver ses propres priorités.

Mais généralement, ces points de variations sont clairement connus (il est très facile de trouver un tableau récapitulant les différentes fonctionnalités implémentées par les différents compilateurs ) et peuvent, dans bien des cas, ne nécessiter qu'un #ifdef symbole de compilation conditionnelle

- faire du code qui déjà fonctionne (gaffe au code qui tombe en marche)

Sais tu que, pour qui la comprend, la norme prévoit exactement où ton programme a de grandes chances de tomber en marche

Aux erreurs de logique et de conception près, le fait de respecter la norme te donne un très net avantage à ce sujet

- faire du code fonctionnant tant en 32 qu'en 64 bits (facile de tomber dans le piège)

Encore une fois, la norme peut servir de bible sur ce coup là...

Elle prévoit (enfin, je ne sais plus si c'est elle ou si c'est la norme C++) une série de typdefs qui permet de s'assurer que l'on utilise, par exemple, le bon type lorsque l'on caste un pointeur (unsigned int en 32 bits, unsigned long long en 64 bits, enfin, dépendant de l'architecture )

Il est, en connaissant et en comprenant la norme, beaucoup plus simple de faire du code qui compilera sur toutes les architectures, qu'elles soient 32bits ou 64 bits, et bien au delà

- ne pas ré-inventer la roue, utiliser la stl

+1, et commencer par bannir les char * et autres fonctions str* issues du C

- ne pas forcément non plus embarquer une bibliothèque qui ne fera qu'alourdir l'exe final (qui a dit qt?)

1. je n'ai parlé de Qt que parce qu'elle était citée dans le sujet, mais c'est quelque peu "hors scope" étant donné que la question de base a surtout trait aux compilateurs et aux EDI
2. je ne suis pas sur du tout que le bibliothèque graphique du framework .Net n'alourdira pas tout autant l'exécutable final (la portabilité en moins)
3. Comparé aux autres bibliothèques graphiques, elle me semble sincèrement mieux conçues qu'un certain nombre
4. la seule chose qui ne soit pas "hors scope" concernant Qt, c'est son outil QtCreator, et il est tout à fait en mesure de fournir des applications consoles qui n'incluent strictement rien de Qt

[stardeath]

Hé bien, je n'en suis pas si sur...

A la limite près que l'on est, parfois, limité par le support de la norme par le compilateur (je n'en reviens par exemple toujours pas que VS2012 ne supporte pas les fonctions marquées delete !!!), si tu respecte la norme, ton code sera vraisemblablement portable.

je dirai bien oui, si seulement tous les programmes jamais écrit jusque là n'étaient composés que de c++, ou alors qu'il n'y ait qu'un seul fournisseur de compilateur. hors ce n'est pas le cas, rien qu'à voir la liste de cas touchy que ne gère pas gcc pour comprendre que ce n'est pas parce que tu fais du code à priori valide que le compilateur va faire un exécutable qui le sera.

d'ailleurs [code de gueule] ce n'est pas parce que la mode est de sortir des nouvelles versions tout juste après voir même avant la rédaction des normes que c'est forcément une bonne idée, la nouvelle norme c++ a mis plusieurs années avant de voir le jour, je vois pas pourquoi on devrait donc exiger que les compilateurs doivent déjà la supporter à 100%, le tout sans bug avec une utilisation en prod sûre. [/code de gueule]

Les points de variations éventuels sont, justement, dus au fait que certains compilateurs ont mis l'accent sur certaines nouvelles fonctionnalités qu'ils ont préféré implémenter avant d'autre, et que chaque équipe de développement a pu trouver ses propres priorités.

Mais généralement, ces points de variations sont clairement connus (il est très facile de trouver un tableau récapitulant les différentes fonctionnalités implémentées par les différents compilateurs ) et peuvent, dans bien des cas, ne nécessiter qu'un #ifdef symbole de compilation conditionnelle

ce qui nous donne une jolie contrainte (je ne dis pas que c'est insoluble, attention) qui à force de s'accumuler, rempli notre code de compilation conditionnelle, pas forcément nécessaire et qui rende le code assez imbuvable (exemple le stdint portable, une horreur, ça marche certes mais bonjour le mal de tête)

Sais tu que, pour qui la comprend, la norme prévoit exactement où ton programme a de grandes chances de tomber en marche

Aux erreurs de logique et de conception près, le fait de respecter la norme te donne un très net avantage à ce sujet
Encore une fois, la norme peut servir de bible sur ce coup là...

nombre de développeurs ne lisent pas la bible, c'est intéressant mais comme au dessus, assez imbuvable.

Elle prévoit (enfin, je ne sais plus si c'est elle ou si c'est la norme C++) une série de typdefs qui permet de s'assurer que l'on utilise, par exemple, le bon type lorsque l'on caste un pointeur (unsigned int en 32 bits, unsigned long long en 64 bits, enfin, dépendant de l'architecture )

Il est, en connaissant et en comprenant la norme, beaucoup plus simple de faire du code qui compilera sur toutes les architectures, qu'elles soient 32bits ou 64 bits, et bien au delà

il n'y a pas que ça à faire gaffe, les promotions implicites peuvent être un danger si on ne fait pas gaffe, tout comme dépasser la capacité d'un int32 qui sera très rarement signalé jusqu'au jour où ton programme crachera.

+1, et commencer par bannir les char * et autres fonctions str* issues du C

preuve que la norme ne fait pas tout, vu le vestige de fonctions, méthodes de classes qui ne prennent que des char* dans la stl.
ou encore les incohérences de nommage (qui se souvient des setw et setprecision)

1. je n'ai parlé de Qt que parce qu'elle était citée dans le sujet, mais c'est quelque peu "hors scope" étant donné que la question de base a surtout trait aux compilateurs et aux EDI
2. je ne suis pas sur du tout que le bibliothèque graphique du framework .Net n'alourdira pas tout autant l'exécutable final (la portabilité en moins)
3. Comparé aux autres bibliothèques graphiques, elle me semble sincèrement mieux conçues qu'un certain nombre
4. la seule chose qui ne soit pas "hors scope" concernant Qt, c'est son outil QtCreator, et il est tout à fait en mesure de fournir des applications consoles qui n'incluent strictement rien de Qt

je parle pas forcément de framework .net mais plutôt de win32 natif, faire un fenêtre avec 3 boutons, 2 champs de texte n'est pas des masses plus énergivore en temps de programmation qu'utiliser qt, mais par contre on gagnera en mémoire vive et disque dur, c'est stupide de ma part de dire ça à l'heure où la moindre machine est un dual-core avec 8Go de ram, mais n'avoir comme réponse que le tank alors qu'une tapette à mouches suffit à tendance à m'exaspérer.

qt est peut être bien conçu (moi je trouve pas mais bon) mais ça n'en reste pas moins une dépendance pas gratuite à intégrer tant en code qu'en toolchain et même en bibliothèques à fournir avec l'exécutable.

et pour finir avec qt, je ne souhaite à personne de tomber sur des bugs dans qtgui qui fait que tu finis par écrire un code par os pour résoudre ça.

mon point de vu étant finalement que faire un programme un tant soit peu complexe n'est déjà pas toujours facile, que c'est pas vraiment pertinent de se compliquer la vie amha.