Version imprimable
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 :)
Commence par GCC.
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.
Non, bien heureusement.Citation:
Envoyé par Devland
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).Citation:
Envoyé par JolyLoic
Bonjour,
Je confirme, on peut vendre des applications développées avec visual C++ express.Citation:
Citation:
(faut-il prévoir de payer des droits si on vends des programmes réalisés avec le compilateur?)
Non, bien heureusement.
Source : http://cplus.about.com/od/softwarere...r/vcee2005.htm
Voici la phrase intéressante :
Citation:
Can I use Express Editions for commercial use? Yes, there are no licensing restrictions for applications built using the Express Editions.
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 :roll:.
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.
cygwin contient un autre portage de GCC sous Windows.
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).
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à.Citation:
Envoyé par 3DArchi
Pourquoi?Citation:
Envoyé par 3DArchi
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).
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.Citation:
Envoyé par Jean-Marc.Bourguet
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 ;)
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 :)
Non, pas du tout.Citation:
Envoyé par Devland
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.
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.
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.Citation:
Envoyé par Florian Goo
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.
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.Citation:
Envoyé par 3DArchi
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.
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.Citation:
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).
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.
+1 :)Citation:
Faut arrêter l'égalité "tout ce que fait Microsoft" = mauvais.
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.Citation:
Envoyé par 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 (http://matthieu-brucher.developpez.c...visual-studio/)Citation:
Envoyé par white_tentacle
C'est seulement dans Team Suite, j'ai l'impression ? Ça explique que je ne l'ai jamais vu :)Citation:
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
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.Citation:
Envoyé par white_tentacle
Pour les erreurs de débogage, ne pas oublier ce problème non plus.
Intéressant. Jamais rencontré ce problème.
C'est très loin de représenter mon avis. Professionnellement, j'ai plus souvent utilisé Visual, et sans regret. J'apprécie vraiment son debugger. Dans les dernières versions, je trouve même assez pratique pour certains aspects de multi-thread. Pour la complétion, c'est vrai qu'elle est parfois un peu limite par rapport à d'autres éditeurs. Par contre, je pense que pour un débutant sous Windows, ça fait un bon outil. L'IDE a aussi amélioré sa gestion des solutions.Citation:
Envoyé par Matthieu Brucher
Mais dès que je le peux, j'utilise le même code source sur des projets en visual et en gcc/Code::Block. Les deux compilations ne donnent pas forcément les mêmes résultats (en terme de warning ou d'erreur de compilation) : parfois les messages sont plus compréhensibles sous Visual et parfois c'est gcc. Je ne connais pas la norme sous le bout des doigts, donc l'utilisation des 2 compilo permet aussi de lever d'éventuels problèmes de portabilité du code.
[EDIT]: mais au final, ce genre de discussion peut rapidement dériver au troll. A chacun d'utiliser les outils qu'il appréhende le mieux. Ensuite, quand on est familier avec le langage et qu'on a un peu de bouteille en développement, ça devient une question plus accessoire. On s'adapte !
Effectivement. Et utilisant en plus Intel C++ (plusieurs versions) ou pgi, xlc++ et consort, à chaque fois c'est différent. Et ça a l'avantage de bien faire ressortir les bugs à force.Citation:
Envoyé par 3DArchi