HaskellTu regretteras vraiment pas le voyage.
Clang compile plus rapidement que g++ (ok, c'est pas très dur...) et donne des messages d'erreur plus clairs, avec par exemple des "^" pour indiquer à quel endroit l'erreur se situe, genre :
Et sinon, const est important c'est certain. "const" à l'extrême ça donne comme en Haskell, tout immutable. C'a ses défauts, mais aussi beaucoup, *beaucoup* d'avantages.
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3blabla< <int > var; ^
L'avis du concepteur de C# et de la plateforme .NET est un peu biaisé, non ?
Evidemment, sur du code pas terrible const sera mal (pas/trop ?) utilisé, mais dans des libs dignes de ce nom c'est bien utilisé et ça te permet de comprendre plus rapidement ce que font les fonctions et les garanties qu'elles t'offrent. Il suffit juste d'avoir le réflexe. Mais comment est-ce que ça, ça pourrait être un défaut/désavantage de C++ ? Après c'est sûr le langage n'empêche pas aux mauvais programmeurs C++ d'écrire des conneries, mais là il faut remettre en question la formation du gars, pas le langage.
Si je ne me trompe pas gcc indique le caractère(et la ligne) où se situe l'erreur, et à partir de là ça ne doit pas être trop dur d'avoir un comportement équivalent, non ?
Et pour ce qui est de l'efficacité des outils, elle est assez variable : après avoir utilisé quelques temps Code Blocks je pensais qu'effictevement un outil (gratuit) parsant efficacement le C++ n'était pas à l'ordre du jour, mais j'ai été agréablement surpris en découvrant QtCreator puis KDevelop (pour ne citer qu'eux). Il faut donc faire très attention aux conclusion hative. (Et ne pas éternellement reprendre les meme arguments, meme si le C++ evolue lentement, ce n'est pas le cas des edi, debogueur, compilateur, ...)
Oui, mais desfois il n'est pas aussi précis qu'on voudrait. Et puis c'est quand même plus agréable/pratique d'avoir le p'tit "^" qui te dit où est ton erreur.
De toute façon, le parseur de clang est meilleur, il garde plus d'infos au fil du parsing. Un exemple c'est que quand t'as des erreurs dans des macros, il te donne les étapes "d'évaluation" de la macro, et te dit où est l'erreur.
Le gros point d'interrogation c'est, dans quelques temps, de voir comment sera le code généré niveau performances (et taille, mais ça à la rigueur...), en comparaison avec gcc, VC++ et ICC au moins.
Je suis d'accord que la seconde solution est bien plus pratique et lisible mais je voulais souligner que mettre en place un systeme similaire au dessus de(ou dans) gcc n'est pas extremement compliqué vu qu'il indique la position du caractère(il existe bien des outils pour decrypter les messages d'erreur de template, alors pourquoi pas?) :
no such operator+ line 24:7:
a + b + c + foo(z)
Je ne voulait pas partir dans un débat dessus : d'ailleurs clang est un exemple concret de l'évolution des outils( il n'y aurait pas vraiment d'interet de creer un nouveau compilateur qui soit moins efficace(dans tous les sens du terme, rapidité de compilation, lisibilité des messages) que ceux qui existe déjà...)
Tu as raison en ce sens que des langages tels que Java et C# sont plus limités: ils nécessitent une plate-forme logicielle sous-jacente, avec ses inconvénients. L'avantage est qu'ils sont mieux adaptés aux besoins des logiciels pouvant se limiter à cette plate-forme, ce qui représente tout de même un vaste éventail de possibilités.
Je ne suis pas en guerre ouverte contre C++. Je l'utilise quotidiennement. J'ai travaillé dans les jeux vidéos et je comprends pourquoi il est utilisé dans ce domaine, ainsi que dans les systèmes temps réel et critiques (quoi que dans ce cas j'ai entendu dire que C était prédominant). Ce que je dis, c'est qu'on fait toujours mieux d'utiliser l'outil le plus adapté pour le travail à effectuer. Dans le cas d'une application pour PC, client ou serveur, on fait mieux de se tourner vers des outils spécifiquement conçus pour faciliter le travail (tels que Python, C#, etc.), qu'une solution générale qui peut faire la tâche. Par exemple, dans les jeux vidéos, seul le moteur est codé en C++: l'AI est souvent scripté en Lua, et les outils sont écrits en C#.
Ça ne sert à rien, donc, d'essayer de nier les limitations du C++ comme si c'était une solution idéale à tout coup. On se tire dans le pied à choisir un outil parce qu'on le "préfère" plutôt que de choisir l'outil réellement le plus adapté.
Reste qu'il est rare qu'une application C# dépende d'une librairie de sockets externe, parce que la plateforme .NET en fournit une très bonne. Et donc la richesse des librairies standards dans de tels langages réduit les dépendances externes, ce qui simplifie la tâche tant au programmeur (qui n'a qu'à maîtriser la librairie standard plutôt que d'apprendre différents API) qu'à celui qui essaye de builder l'application après lui. Un système de gestion tel que celui de Debian est très bien, reste que ce n'est pas non plus propre à C++, que toutes les applications C++ n'en tirent pas parti, et qu'on ne peut en profiter que sur les OS qui supportent ce système. Je crois que tu minimise le problème trop facilement. Il n'est pas rare de tomber sur un vieux projet dont les dépendances sont des versions qu'on ne trouve même plus sur le net, et on est assez mal pris pour le faire compiler.De plus, le problème des dépendances est un problème liés aux outils. Sur ma debian, si je télécharge un paquet source d'un logiciel depuis les dépots, j'ai toutes les dépendances que je n'ai pas déjà (car oui, j'ai déjà pas mal de dépendances "classiques" déjà présentes) qui s'installent toute seule. Si je le télécharge depuis le net, les dépendances sont souvent listés et ca me prends 5 mins à installer.
J'imagine que tu fais largement référence à shared_ptr ou à un compteur de référence similaire. Sauf qu'avec shared_ptr, si tu as des références cycliques (a -> b -> c -> a), le compteur de référence n'est jamais décrémenté, et boum, fuite de mémoire. Donc, il te faut ajouter un weak_ptr quelque part dans la chaîne. Par ailleurs, si la performance est réellement critique (comme c'est souvent le cas quand on choisit C++), tu ne seras probablement pas satisfait des allocateurs par défaut (qui n'ont aucune considération pour la localité de référence). Et donc, même les objets RAII ne te dispensent pas entièrement de réfléchir à comment la mémoire doit être gérée. Un environnement géré tel que la JVM ou le CLR, oui.Je sais pas comment tu codes mais je ne gère (presque) rien manuellement de la mémoire, des classes RAII-ssante offrant tout ce dont j'ai besoin. Je ne vois pas comment un GC pourrait m'offrir quelque chose puisque je ne fais rien de particulier pour gérer ma mémoire.
...pas en C# (ce que tu citais). Je te faisais simplement valoir qu'il est facile d'avoir une vue d'ensemble d'une classe dans un langage où il n'y a pas de fichiers d'en-tête, soit, tous les langages sauf C, Objective-C et C++ dans le fond.On a les fichiers d'en tête pour ca [fournir une vue d'ensemble] plus tous les outils externes qui peuvent exister à coté.
Je n'ai pas dit que les temps de compilation du C++ étaient inexplicables. J'ai dit qu'ils étaient long. Alors, quand on essaye de le nier (voir arguments auxquels je répondais), je fournis des exemples et des explications.Tu as toi même donné la réponse. Une compilation C++ fait beaucoup plus de chose qu'une construction en Java/C#. Normal que ca prenne plus de temps. Faudrait comparer ce qui est comparable. Et joel marque un point avec les headers précompilés. Et clang/llvm devrait aussi réduire les temps de compilation.
Quand tu dis "faudrait comparer ce qui est comparable", je ne vois pas trop ce que tu veux dire. On peut très bien comparer le temps moyen qu'un développeur passera à attendre de pouvoir tester son nouveau code, selon le langage qu'il utilise, et en arriver à la conclusion qu'il serait mieux servi par autre chose que C++ sur ce plan (et je dis bien sur ce plan: le temps de compilation.)
Comme j'ai dit, étant donné que je n'utilise pour ainsi dire jamais des tableaux C, je suppose toujours qu'il s'agit d'objets. Le seul tableau C que j'utilise réellement c'est la string C, parce qu'elle est partout dans les librairies. Et tout le monde sait que "const char*" est une string C et non un pointeur vers un caractère.Tous les exemples que tu as fournis sont bourrés de pointeurs dans les paramètres des fonctions, comment tu sais si ce sont des tableau ou des objets dans ce cas sans te référer aux commentaires ?
Ah, si bar() doit créer une ressource et la retourner, je suis entièrement d'accord qu'elle doit retourner un shared_ptr. Surtout pas une référence.Si foo prend un pointeur, ca oblige bar a renvoyer un pointeur. Pour éviter les fuites de mémoire, un pointeur intelligent c'est mieux et comme y'a pas de conversion automatique de boost::shared_ptr<T> vers T*, tu te retrouves à utiliser get().
Code : Sélectionner tout - Visualiser dans une fenêtre à part foo(bar()).
Comme les outils que je mentionnais dans la phrase suivant celle que tu citais.Envoyé par yan
![]()
Je vais prendre le C# comme exemple car c'est celui que je connais le mieux. On pourrait sûrement faire un argumentaire similaire pour un autre langage et je ne dis pas que C# est la seule solution.
Cela dit, en quelques minutes, voici ce qui m'est venu en tête (je pourrais continuer):
Librairies cohérentes
Un projet C++ typique utilise 5 librairies différentes que le programmeur devra dénicher par lui-même en faisant sa petite recherche sur internet, chacune avec sa propre philosophie, ses normes de codage, et sa documentation, la qualité de cette dernière alternant entre qualité MSDN, « lisez le code source » et « un document word un peu vieux ». Les librairies .NET sont intégrées, cohérentes, documentées rigoureusement et à l’aide de milliers d’exemples fonctionnels, sont généralement plus faciles à utiliser que les librairies C++, et couvrent la plupart des besoins d'une application PC (client ou serveur) typique.
Temps de compilation
Tout programmeur C++ connaît la frustration de perdre une ou plusieurs minutes parce qu’il a oublié un point-virgule dans un fichier d’en-tête. Ce problème n’existe tout simplement pas en C#, dont le modèle de compilation assure des délais minimaux entre deux cycles modification-test.
Outils fiables
Le langage C# a été pensé pour bien s’intégrer dans un environnement de développement. La complétion de code, les refactorings, les tooltips, le débogage et autres aides fonctionnent de façon fiable, rapide et efficace. Plusieurs programmeurs rapportent que ce genre de « détails » est ce qui augmente le plus leur productivité (exemple: http://stackoverflow.com/questions/1...ains-of-c-vs-c)
Composants
Sur .NET, du code == une composante, automatiquement. Les assemblies .NET incluent un mécanisme de gestion des versions, de vérification de l’intégrité du code et de son auteur. Les composantes .NET sont compatibles entre elles, peu importe sur quel compilateur et dans quel langage elles ont été écrites (C#, VB, IronPython, IronRuby, F#, Boo, Cobra, C++/CLI et des dizaines d’autres supportent le CLI): il est donc facile d'utiliser plusieurs langages dans le même projet.
Accès à de puissantes librairies graphiques
Winforms et WPF ne sont tout simplement pas disponibles en C++.
Sécurité
C# rend impossible tout une gamme d’erreurs communes en C++ : débordement de bornes, pointeurs invalides, lecture d’une variable non initialisée, la plupart des cas de fuite de mémoire, réinterprétation invalide d’un type, etc. Il est donc plus facile d’écrire du code sécuritaire en C#.
Expressivité
C# supporte
- la réflexion (au-delà de dynamic_cast et typeid),
- les évènements,
- la génération d'itérateurs (yield return)
- les délégués,
- le typage dynamique (facilitant l’interopérabilité avec Python, Javascript, XML, etc.),
- les requêtes LINQ,
- les méthodes d’extensions,
- les classes et méthodes partielles,
- les propriétés,
- élimine entièrement les fichiers d’en-tête et tous leurs problèmes associés (ordre d’inclusion, dépendances cycliques, duplication de code, erreurs de linker, etc.),
- élimine les macros,
- offre un modèle orienté-objet cohérent (tout est un objet, sans exception),
- différencie au niveau du langage les types « valeurs » des types « identité » (struct vs class),
- supporte en bonne partie programmation fonctionnelle,
- supporte un style de commentaire standard (commentaires XML)
- (prochaine version) supportera le concept de « tâche asynchrone », automatisant le multi-threading dans une gamme de scénarios communs.
Performance
Souvent, la solution "naïve" C# est bien plus performante que la solution "naïve" C++, et quoique le C++ puisse arriver à de meilleurs résultats, il faudra plus de travail pour y arriver. Exemple: http://www.codinghorror.com/blog/200...nce-again.html.
Facile à prendre en main
Les développeurs s’entendent à général à dire qu’il faut moins de connaissances pour être productif en C# qu’en C++. Ceci est une conséquence normale des avantages déjà mentionnés. Par conséquent, à expérience égale, un développeur est plus productif en C# qu’en C++.
La question est "est-ce que les gains de productivité éventuels compensent le temps d'adaptation?", et cela dépend de la longueur et du type de projet. Mais je crois que pour un bon programmeur C++, le temps d'adaptation sera relativement court. Un des objectifs de C# est d'être intuitivement familier aux développeurs C++.Et dans le cas d'un développeur connaissant C++ mais pas C# ?
peut-être ne connais-tu pas Qt ?
Avec le trio C++-Qt-boost,je ne vois pas en quoi on serait plus productif en C#!
Hors mis les outils type resharper, c'est la même chose!
le problème de la recompilation est un faux problème arrêtez avec ça! on ne passe pas ça journée à recompiler !
Pour la sécurité pointeur intelligent+RAII permette de s'affranchir très très facilement de tout problème de fuite de mémoire!
et puis le jour ou notre developpeur C# doit écrire un serveur qui doit tourner sous linux pour des questions de performance , on fait quoi ? on embauche un mec qui sait faire du C++!
Souvent, la solution "naïve" C# est bien plus performante que la solution "naïve" C++, et quoique le C++ puisse arriver à de meilleurs résultats, il faudra plus de travail pour y arriver. Exemple: http://www.codinghorror.com/blog/200...nce-again.html.
Si on parle d'un mec qui connait raisonnablement bien C++, ça m'étonne clairement
quand au async/wait de C# excuse moi lol mais ça revient UNIQUEMENT à lancer une méthode dans un thread soit boost::thread(mafonction); sur le lieu de l'appel
ces benchs sont sans valeur, pour une paire de langage donnné, je te monte 2 source de meme fonctionnalité avec l'ordre voulu sur le classement des langages. Et d'autres part, à part savoir qui à la plus grosse paire, ca n'apporte rien au sujet.
Ca me rappelle ces sempiternels comparaisons trollesque sur JAVA > C++ ou les mecs foutent des new/delete dans une boucle critique :€
Clairement, ni l'un ni l'autre n'a lu l'article dont vous parlez. Guillaume07, parce que le lien était brisé et que tu ne l'as pas remarqué, j'en conclus que tu n'avais même pas essayé de cliquer dessus; Joel, parce que c'est tout sauf un benchmark sans valeur posté pour attirer l'attention, c'est la conclusion d'une série d'articles postés par Raymond Chen (surnommé le "Chuck Norris" de Microsoft, une sommité en C++ et particulièrement Win32, auteur de "The Old New Thing") et Rico Mariani, expert en performance et architecte en chef de Visual Studio.
Si vous êtes au-dessus de ces gars-là, je n'ai rien à dire bien entendu.
Et puis guillaume07 je vais te répondre pour une fois mais j'ai bien peur que ça ne serve à rien.
Premièrement Qt n'est pas WPF, et si tu as travaillé avec les deux tu dois savoir que WPF est une solution supérieure à tous les niveaux (performance, qualité du rendu, flexibilité), et que Qt n'est pas gratuit à moins que tu sois prêt à publier ton code sous license GPL. WPF n'a pas cette restriction, et est fourni gratuitement dans son intégrité avec les versions express de Visual Studio.
Tu peux nier la lenteur de compilation tant que tu veux ça ne change rien. L'ensemble des librairies du langage Go, environ 130000 lignes de code, compile en 8 secondes sur un ordinateur de puissance moyenne (voir à 10:00 environ). Le temps de compilation en Ruby et Python est 0 (parce qu'il n'y a essentiellement pas de compilation). En Java et C#, il est difficile de trouver un projet assez gros pour qu'il prenne plus d'une minute à compiler. En C++, on est plutôt chanceux si un build incrémental prend moins d'une minute. Le projet sur lequel j'ai travaillé cet été utilisait tous les trucs connus pour améliorer les temps de compilation (fichiers cpp "masters", réduction au minimum des dépendances), et sur 3 systèmes Corei7 en parallèle il fallait environ 15 minutes pour faire un debug build (c'était énorme, oui). Un build incrémental prenait environ 1 minute, ce qui est assez pour prolonger indûment les code reviews et ralentir considérablement l'itération modification-test.
Ensuite, écrire un serveur C# sur Linux est tout à fait possible, avec Mono, et Mono est là pour rester. Et comme je l'expliquais au début de mon message, je n'essaye pas de promouvoir C# comme la solution ultime; si on n'aime pas, il y a encore beaucoup d'autres choix. Autres que C++. Par exemple, sur Linux, on peut écrire un serveur très performant en Java; bonne chance pour faire mieux en C++.
Pour ce qui est de async/await, l'idée est justement de ne pas démarrer un thread et d'avoir à gérer la récupération asynchrone des données, les exceptions se produisant dans ce thread, ou l'annulation de la tâche. Pour ceux que ça peut intéresser, Anders Hejlsberg a donné tout récemment une conférence très intéressante à ce sujet. Bien sûr, on peut qualifier tout ça de "bonbon syntaxique", mais bon, les langages de programmation sont essentiellement du bonbon syntaxique: il y a amélioration de productivité quand le bonbon en question te permet de penser à un plus haut niveau d'abstraction, de faire faire le travail fastidieux et sujet à erreur humaine par un compilateur, et c'est ce que async/await va permettre concernant la programmation parallèle.
À ce que je sache, Visual AssistX est le meilleur plugin C++. Tu connais mieux?Envoyé par yen
Il est vrai qu'on a pas mal changé de sujet. Je ne fais que discuter, quoi. Je ne suis pas vraiment en train d'essayer de convertir qui que ce soit à une idée particulière, juste à échanger des idées. Dernièrement, on parlait de la pertinence d'utiliser autre chose que C++ sur PC en général.Envoyé par yen
![]()
Qt est sous LGPL depuis environ 1.5 années ... WPF est supérieur, merci de cette argumentation extrèmement pertinente. WPF n'est pas portable en l'occurrence, vu que personne chez Mono n'est intéressé par le réecrire. C'est déjà un défault majeur. Pour le reste difficile de tester, je n'utilise pas de plateformes supportés par WPF.
async/await, whoot, std::promise, std::future, tout ça. boost::asio fournit un framework pour l'asynchronisme en C++ depuis un petit moment aussi. Quand à ton dernier lien, il est illisible, ma plateforme n'ayant pas de client silverlight.
Ton précédent lien, démontre, que pour un certain problème, C# fournit une réponse plus rapide que C++. Ça ne prouve rien en général, et tout le monde est d'accord pour dire que les stream ne sont probablement pas la plus grande réussite de la SL C++.
Et sinon la compilation de C++ est plus lente que tout ce que tu as cité. En même temps, tu as beaucoup plus d'erreur à l'execution, ce qui n'accélère pas vraiment les choses. C'est ensuite un trade-off entre l'écriture des TU et le temps de compilation, en espérant avoir un taux de couverture qui tend vers 100% (ce qui n'arrive que dans des cas très précis, et où en général on n'ecrit pas en python).
Et il est clair que tu n'as pas lu les articles de Raymond Chen justement... Il a benché les IO, je vois pas en quoi c'est généralisable aux C++ tout entier. (d'autant plus qu'on le sait tous les IO sont vraiment le point faible du C++ et ils sont lent il faut bien le dire, c'est d'ailleurs ce que M. Chen voulait démontrer).
Aurais-tu une source fiable concernant ce nombre ? Non pas que je sois en désaccord avec, juste que je n'en suis pas convaincu.
Tout à fait d'accord. Ceci étant ce problème se retrouve dans à peu près tout les langages dès que tu sors de la bibliothèque standard (voire même dans cette bibliothèque pour certain). Et je ne connais pas de langage où on ne se retrouve pas avec plusieurs bibliothèques tierces au bout de quelques années de vie.
Exemple classique concernant les IO.
Sinon, tu as une liste d'avantages de C# (et encore, certains points sont discutables, mais bon passons dans l'ensemble je suis plutôt d'accord, ce sont bien des avantages et, au passage, je n'ai jamais prétendu que C# n'avait aucun avantage). Mais en quoi ça rend le C# plus adapté d'une manière générale ?
Dois-je comprendre qu'il n'a aucun inconvénient ? Que ma base de code en C++ je peux la mettre à la poubelle ? Que si mon code doit tourner sur des PC équipé d'un autre OS que Windows (et de Linux si on tape dans la partie supportée par mono) ou n'ayant pas assez de ressources pour faire tourner le framework .Net on les met à la poubelle et on en achète d'autre ? Aucun de ces avantages n'est disponible lorsqu'on utilise C++/CLI ?
Pour préciser ma pensée, je ne nie pas que C# ou n'importe quel autre langage d'ailleurs puissent avoir des avantages par rapport à C++ ou qu'ils ne puissent pas être plus adaptés dans certains cas.
Ce qui me gène dans tes propos initiaux c'est le côté absolu du jugement "sur PC, il vaut mieux utiliser C# ou Python que C++".
Il bench des foutus entrées/sorties quoi pas du code de calcul, who cares ...
Perso, tu vois je passe ma journée à ecrire du HPC en C++, merde, je suis à 99% de la vitesse du FORTRAN :€ Pas mal pour un language foireux.
Et fichtre, franchement, j'attendais mieux de chuck norris.
J'attends avec impatience ta prochaine pirouette.
Tu veux un plugin pour faire quoi?
Comparer un seul outils est dire que
me parait bien extrême.qualité et la fiabilité des outils C++ sont inférieurs
Comme le sujet est sur le mot clef const, je voulais revenir sur le manque du const en java(en C# il y as des équivalents mais je ne sais pas jusqu’où).
Personnellement, je trouve que le manque de const en java et le "tout est référence" rend le langage trés compliqué sur la gestion mémoire. Par exemple, j'ai une classe qui propose une interface listener pour envoyer des données. Si je veux être sûre que le listener qui s'y connecte ne fasse pas n'importe quoi, je dois :
- créer une classe spécifique immutable.
- ou mettre les setter en private. Donc immutable pour l'extèrieur du package.
- ou créer une interface immutable à mon instance avec des exceptions sur les fonctions mutateur(http://www.javamex.com/java_equivale...nst_java.shtml)
- ou je retourne un clone de ma donné à chaque listener.
- Si je donne accès à une instance d'un classe mutable, je doit faire un clone
Alors qu'en C++ je peux simplement faire
- un passage par copie
- une référence constante
C'est peut être qu'une question de goût, mais je trouve le const simplifie énormément les choses.
Perso, je trouve que dire qu'avec JAVA "on développe plus vite" n'est qu'illusoire, car je trouve que le "tout est référence" permet surtout de faire tomber un programme en marche. Et le temps de débogage peut se compliquer énormément. Et c'est là où le const aurais fait la différence et empêcher la majorité des erreurs dû au référence.
Après, je n'ai pas des années d’expérience en java et C# donc je me trompe peut être. Mais c'est ce que je constate. Et pas qu'avec des débutants...
Pour atteindre la performance du code C#, Raymond a dû non seulement contourner les streams C++, mais aussi:
- la conversion de caractères (<locale> )
- les strings (<string>)
- l'allocateur par défaut
Et comme il s'agit (à part peut-être <locale>) de types très couramment utilisés, l'exemple est pertinent dans beaucoup de scénarios.
Complétion de code, refactorings, aides visuelles, aides à la sélection, à la copie, etc. Regarde par exemple ce que Coderush peut faire: http://www.devexpress.com/Products/V...ance/index.xmlTu veux un plugin pour faire quoi?
Je dois ne pas comprendre quelque chose dans ton exemple, car si ta classe propose une interface listener, alors le listener qui s'y connecte n'a accès qu'aux méthodes de l'interface listener. Donc, le listener ne peut pas faire n'importe quoi, et si ta classe ne se modifie pas elle-même dans son implémentation de l'interface, alors le listener ne peut pas la modifier. Il pourrait toujours faire un cast dans le type dérivé, mais peut aussi faire un const_cast en C++.Par exemple, j'ai une classe qui propose une interface listener pour envoyer des données.
Non, je dis ça comme ça, d'expérience, et j'exagère peut-être légèrement. Mais je dirais avec une certitude assez élevée que la plupart des projets C++ utilisent au moins 3 librairies complètement différentes: la librairie C, la C++SL, et quelque chose d'autre (boost, Qt, GTK, SDL, POSIX, etc.)Aurais-tu une source fiable concernant ce nombre ? Non pas que je sois en désaccord avec, juste que je n'en suis pas convaincu.
Certainement. Mais dans bien des langages, il faut des besoins plus spécialisés que "je dois afficher quelque chose à l'écran" pour avoir à sortir de la librairie standard. Et donc, le problème existe ailleurs, mais dans une moindre mesure.Tout à fait d'accord. Ceci étant ce problème se retrouve dans à peu près tout les langages dès que tu sors de la bibliothèque standard (voire même dans cette bibliothèque pour certain). Et je ne connais pas de langage où on ne se retrouve pas avec plusieurs bibliothèques tierces au bout de quelques années de vie.
Je comprends bien ton point de vue et j'apprécie ton discernement.Mais en quoi ça rend le C# plus adapté d'une manière générale ?
Dois-je comprendre qu'il n'a aucun inconvénient ? Que ma base de code en C++ je peux la mettre à la poubelle ? Que si mon code doit tourner sur des PC équipé d'un autre OS que Windows (et de Linux si on tape dans la partie supportée par mono) ou n'ayant pas assez de ressources pour faire tourner le framework .Net on les met à la poubelle et on en achète d'autre ? Aucun de ces avantages n'est disponible lorsqu'on utilise C++/CLI ?
Pour préciser ma pensée, je ne nie pas que C# ou n'importe quel autre langage d'ailleurs puissent avoir des avantages par rapport à C++ ou qu'ils ne puissent pas être plus adaptés dans certains cas.
Ce qui me gène dans tes propos initiaux c'est le côté absolu du jugement "sur PC, il vaut mieux utiliser C# ou Python que C++".
Je trouve que C et C++, particulièrement sur Linux, n'ont pas la place qu'ils méritent. C'est-à-dire qu'ils occupent trop de place. Dans mon domaine de prédilection, soit les jeux, dès que je trouve un projet intéressant je remarque qu'il est en C, ou en C++. Pourquoi? Ce n'est pas la seule solution pour écrire du code natif; il y a D, Go, et probablement d'autres. Et si on n'a pas besoin que le programme soit en code natif, il y a énormément de choix du côté des langages gérés, chacun avec différents avantages et inconvénients.
Quand on prend C++ pour ce qu'il est, ce n'est pas un langage particulièrement intéressant, à part peut-être pour la méta-programmation de templates à la syntaxe hermétique (templates qui n'ont jamais été conçues pour ça d'ailleurs). C++ tient sa popularité au contexte historique qui l'a vu naître, et de nos jours, au fait que c'est le plus petit commun dénominateur (à part peut-être C) à la majorité des plateformes, et aussi au bagage de librairies qui l'entourent. Sur console, C++ est roi parce que c'est la seule option. La PS3 est fournie avec un compilateur C++ (pas terrible d'ailleurs, EA a dû complètement réimplémenter la STL) et c'est tout. Le scénario est le même pour bien des plateformes. Je trouve que si on a la chance de travailler sur PC et d'avoir tant de choix, autant en profiter.
Donc, à moins d'avoir des besoins spécifiques que seul C++ peut remplir, par exemple, implémentation d'une stratégie particulière de gestion de mémoire, je m'explique mal le choix de C++ en-dehors du fait d'être familier avec ce langage. La plupart des autres langages que je connais sont plus expressifs, moins complexes, offrent de meilleurs librairies standards, facilitent la portabilité entre systèmes (C++ n'est portable que par #ifndef WIN32 #elif defined ...), et quoiqu'ils aient leurs inconvénients aussi, ceux-ci ne posent souvent pas vraiment de problème. Par exemple, le gros inconvénient d'une application C#, c'est la dépendance sur .NET. Bon, mais .NET est installé sur 90% des PCs, et il est trivial d'avoir un installeur qui se charge d'aller le chercher si nécessaire.
Reste que WPF est disponible en C# et pas en C++. Qt, lui, a des bindings pour beaucoup de langages incluant C#.Qt est sous LGPL depuis environ 1.5 années ... WPF est supérieur, merci de cette argumentation extrèmement pertinente . WPF n'est pas portable en l'occurrence, vu que personne chez Mono n'est intéressé par le réecrire. C'est déjà un défault majeur. Pour le reste difficile de tester, je n'utilise pas de plateformes supportés par WPF.
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Partager