Discussion :

[Devland]

Bonjour

D'après vous quel serait le meilleur choix de compilateur C++ sur PC pour créer des programmes sous Windows ? (faut-il prévoir de payer des droits si on vends des programmes réalisés avec le compilateur?)

Serait-il aussi le meilleur pour créer des 'codes compilés' utilisables en interaction avec d'autres languages comme Python ou Ruby ?

Merci

[loufoque]

Commence par GCC.

[JolyLoic]

Le leader du marché sous windows est Visual C++. Une version d'entrée de gamme (nommée express) gratuite existe.

Il existe aussi gcc qui est totalement libre et existe aussi sous d'autres environnements. Selon la version que tu utilises sous windows, il est plus ou moins à jour.

(faut-il prévoir de payer des droits si on vends des programmes réalisés avec le compilateur?)

Non, bien heureusement.

[white_tentacle]

(faut-il prévoir de payer des droits si on vends des programmes réalisés avec le compilateur?)

Non, bien heureusement.

Si tu vends des programmes compilé avec visual studio, il te faut une licence visual studio, non ? (express est pour le non commercial/éducatif uniquement il me semble).

[wakan]

Bonjour,

Citation:
(faut-il prévoir de payer des droits si on vends des programmes réalisés avec le compilateur?)
Non, bien heureusement.

Je confirme, on peut vendre des applications développées avec visual C++ express.
Source : http://cplus.about.com/od/softwarere...r/vcee2005.htm
Voici la phrase intéressante :

Can I use Express Editions for commercial use? Yes, there are no licensing restrictions for applications built using the Express Editions.

[Florian Goo]

Pour information, le portage de GCC sous Windows s'appelle MinGW (Minimal GCC for Windows).

Je suis tenté d'argumenter en la faveur de GCC, mais ça aurait toutes les chances de faire partir le sujet en troll .
De toutes façons, les deux sont de qualité tout à fait convenable ! Même si GCC est mieux ^^

Avec ça, je te conseille Code::Blocks comme EDI.

[Luc Hermitte]

cygwin contient un autre portage de GCC sous Windows.

[3DArchi]

Le compilateur est en partie une affaire de goût. Visual est très laxiste vis à vis de la norme, mais a, à mon avis, un atout majeur : son debugger. gcc suit plus la norme ce qui te garantie (à peu près) que tout ce qui compile avec gcc compile avec un autre compilateur.
Ensuite, gcc ou visual Express pour du développement sous Windows nécessitent soit l'utilisation de l'API Win32 pour les IHMs, soit l'utilisation de librairie tierce (type wxWidget). Visual C++ en version payante est fourni avec tout l'attirail des MFC, qui permettent de faire des IHMs sans d'autres librairies. Les MFC sont complexes.
Enfin, pour utiliser gcc, il est quand même conseillé de passer par un IDE (type code::block). Visual comporte son propre IDE (Visual Studio).

[Cheps]

Le compilateur est en partie une affaire de goût. Visual est très laxiste vis à vis de la norme, mais a, à mon avis, un atout majeur : son debugger.

Je trouve que MS s'est bien amélioré du côté du respect de la norme. On est loin du foutage de gueule de VC++ 6 de ce côté-là.

[Jean-Marc.Bourguet]

Enfin, pour utiliser gcc, il est quand même conseillé de passer par un IDE (type code::block).

Pourquoi?

Je crois avoir essaye tous les EDI disponibles sous Linux -- en tout cas, j'en ai essaye une serie -- aucun ne s'est revele capable d'etre utilisable dans mon environnement. J'en suis toujours revenu a ce que j'utilisais en 1991: emacs + gdb sous emacs.

Au mieux, ces essais se concluaient relativement vite: une bonne partie des EDI sont (etaient? j'ai pas envie de refaire les essais presque exhaustifs que j'ai fait il y a deux ans quand je suis passe sur Linux au boulot, j'utilisais Workshop sous Solaris avant, avec Workshop configure pour utiliser emacs comme editeur; j'ai bien ecrit Workshop, sunstudio a le meme probleme qu'eclipse d'etre d'une lenteur abominable, et en plus sous Linux dbx crashe trop souvent sur notre executable compile avec gcc pour etre utilisable) en effet incapables de traiter un projet qui ne respecte pas leur notion de ce que doit etre la structure d'un projet.

Au pire, j'ai perdu beaucoup de temps pour me rendre compte que je n'arrivais pas a en sortir une perf adequate (eclipse par exemple, le pas a pas prenait 10s montre en main et j'ai passe pas mal de temps a chercher a le configurer).

[3DArchi]

Pourquoi?

Je corrige un peu ce que j'ai dit: Pour débuter, un IDE t'offre une 'tout-en-un' qui te simplifie la vie.
Après pour des projets plus complexes, j'avoue pour ma part être toujours passé par les possibilités d'extensions des éditeurs, éventuellement du makefile à la main, et une pléthore d'outils en pre ou post build. Mais, là ça dépend certainement du parcours de chacun

[Devland]

Merci beaucoup pour vos réponses

Si je comprends bien si on veut faire beaucoup de développement pour Windows (Microsoft) il peut être bien de choisir un produit comme le Visual C++... surtout si on veut envisager de faire du graphisme un peu 'elaboré'...

Si Windows n'est pas la priorité et que l'on veut une portabilité (compatibilité)plus aisée GCC peut être un choix plus judicieux...

Merci

[Florian Goo]

Si je comprends bien si on veut faire beaucoup de développement pour Windows (Microsoft) il peut être bien de choisir un produit comme le Visual C++... surtout si on veut envisager de faire du graphisme un peu 'elaboré'...

Non, pas du tout.

GCC aussi est très bien pour faire des choses très élaborées, voire mieux que Visual C++ pour certains !
En toute objectivité, le débat est plus complexe que ça. En aucun cas on ne peut statuer sur une domination claire de l'un sur l'autre.

Après, la portabilité du code, c'est toi qui la crée. Aucun compilateur ne t'empêchera de faire du code non-portable.
Et faire un code uniquement compatible avec Windows, cela me semble aussi dommage que de faire un site optimisé pour Internet Explorer.

En fait je pense plutôt que c'est une question de gout, voire de philosophie (libre/propriétaire).

En ce qui concerne le graphisme, le choix qui importe le plus (après celui du langage, bien vu pour le C++) est à mon avis celui de la bibliothèque utilisée.

[loufoque]

Visual C++ a un environnement de développement intégré et est réellement conçu autour, alors que GCC est un compilateur seulement, ce qui n'empêche pas d'avoir des environnements de développement qui l'utilisent.
C'est ça, en fait, la différence principale.

Personnellement je préfère un bon éditeur texte qu'un EDI.

[Matthieu Brucher]

Pour information, le portage de GCC sous Windows s'appelle MinGW (Minimal GCC for Windows).

Je suis tenté d'argumenter en la faveur de GCC, mais ça aurait toutes les chances de faire partir le sujet en troll .
De toutes façons, les deux sont de qualité tout à fait convenable ! Même si GCC est mieux ^^

Avec ça, je te conseille Code::Blocks comme EDI.

Le principal avantage de Visual, c'est qu'il a un débuggeur largment meilleur que gdb, même lorsque le code est super optimisé (je ne parle même pas de l'IDE qui est au-dessus de tout ce que la concurrence peut offrir). gdb s'emmêle les pinceaux dans le backtrace quand Visual donne exactement les bonnes informations.
Et sous Windows, je resterai toujours avec Visual (ou le compilateur Intel), sous Linux, ça sera gcc ou icc, avec ses inconvénients de débuggage.

Visual est très laxiste vis à vis de la norme, mais a, à mon avis, un atout majeur : son debugger. gcc suit plus la norme ce qui te garantie (à peu près) que tout ce qui compile avec gcc compile avec un autre compilateur.

Là, tu abuses. OK pour Visual 6, mais là on parle de Visual 9 qui ajoute même des choses qui sont dans les TR du C pour la sécurité. D'ailleurs, dans les fora, on voyait juste les gens qui râlaient que Microsoft avait décidé de mettre un accent sur la sécurité. Mais si c'était dans gcc, là, pas de problème. Faut arrêter l'égalité "tout ce que fait Microsoft" = mauvais.

Par exemple, gcc 4.0 avait un sale bug qui empêchait le SFINAE de fonctionner correctement. Bizarrement, je n'ai jamais eu ce problème sur les compilateurs Microsoft.

[white_tentacle]

Le principal avantage de Visual, c'est qu'il a un débuggeur largment meilleur que gdb, même lorsque le code est super optimisé (je ne parle même pas de l'IDE qui est au-dessus de tout ce que la concurrence peut offrir).

Tu parles de Visual 2005 ? Non, là je ne suis pas d'accord. Le debuggeur intégré est bien, mais loin d'être top. Par contre, windbg est très bien (mais aussi, complexe à utiliser). Tu parles de la pile d'appels sur le code optimisé, mon expérience est qu'elle est régulièrement fausse.

Cela dit, il n'y a pas actuellement de bons débuggeurs pour code optimisé (ça impose d'enrichir les symboles par rapport à l'actuel, entre autres).

Côté IDE, Kdevelop a vraiment beaucoup progressé (et le 4, encore en alpha, semble extrêmement prometteur). Le support C++ de visual laisse trop souvent à désirer (en C#, par contre, c'est super). La complétion se met régulièrement en rideau, propose des choses stupides, etc...

Il manque aussi cruellement un équivalent de valgrind sous visual.

Faut arrêter l'égalité "tout ce que fait Microsoft" = mauvais.

+1

[Matthieu Brucher]

Tu parles de Visual 2005 ? Non, là je ne suis pas d'accord. Le debuggeur intégré est bien, mais loin d'être top. Par contre, windbg est très bien (mais aussi, complexe à utiliser). Tu parles de la pile d'appels sur le code optimisé, mon expérience est qu'elle est régulièrement fausse.

Comparé à ce que gdb me sort (quand il ne plante pas), c'est largment plus fiable. Quand je suis dans la fonction f1, il ne me donne pas le fichier et la ligne de al fonction f2, contrairement à gdb.

Il manque aussi cruellement un équivalent de valgrind sous visual.

Ah, tu n'as pas tout vu alors. Contrairement à valgrind qui fait de l'émulation et donc pas forcément fiable et surtout très lent, Visual Studio propose un profiler par échantillonnage et par instrumentation (http://matthieu-brucher.developpez.c...visual-studio/)

[white_tentacle]

Ah, tu n'as pas tout vu alors. Contrairement à valgrind qui fait de l'émulation et donc pas forcément fiable et surtout très lent, Visual Studio propose un profiler par échantillonnage et par instrumentation

C'est seulement dans Team Suite, j'ai l'impression ? Ça explique que je ne l'ai jamais vu

Cela dit, je pensais plus aux memory leaks qu'au profiling (les gflags et autres, ça marche, mais c'est fichtrement pénible à utiliser).

[Matthieu Brucher]

C'est seulement dans Team Suite, j'ai l'impression ? Ça explique que je ne l'ai jamais vu

Cela dit, je pensais plus aux memory leaks qu'au profiling (les gflags et autres, ça marche, mais c'est fichtrement pénible à utiliser).

Ah oui (j'oublie toujours que valgrind est d'abord un outil pour vérifier la mémoire ) Il y a la macro _CRTDBG_MAP_ALLOC pour aider.

[Médinoc]

Pour les erreurs de débogage, ne pas oublier ce problème non plus.