Et de C++ avec des frameworks qui s'imposent presque en standard.Envoyé par aityahia
Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Discussion :
Et de C++ avec des frameworks qui s'imposent presque en standard.
VB6 est totalement à proscrire et c'est une technologie dépassée par rapport à C#/NET
*C# et .NET supportent enfin le multithreading.
C'était difficile de faire la même chose en VB6.
*les exceptions sont mieux gérées en .NET . Et même pour ce qui est du code non managed
Une dll écrite en C qui plante risque de faire planter le programme VB6 appelant.
*il n'y a pas le "dll hell" qu'il y avait avec VB6.
L'inconvénient majeur de C#/.Net c'est que la technologie est plus lourde donc il faut une machine plus puissante.
Dans quelles couches logicielles ces frameworks s'imposent en standard ? De ce que je connais et peux compiler avec code::blocks ou visual studio c'est plus du domaine de l'utilitaire
Mouais.Dans quelles couches logicielles ces frameworks s'imposent en standard ? De ce que je connais et peux compiler avec code::blocks ou visual studio c'est plus du domaine de l'utilitaire
Je ne considèrerais ni Boost ni Qt comme des "utilitaires". La différence c'est qu'il n'y a pas UNE boîte derrière le C++ pour tout gérer, et surtout le C++ n'a été normalisé qu'en 98 pour la première fois. Avant cela, et encore un peu après, chacun faisait ce qu'il voulait dans son coin.
Au passage, C++0x intègrera pas mal de chose, dont le support *standard* du multithreading, et pas mal d'autres choses intéressantes. Dans un Technical Report de C++0x on pourrait bien avoir le réseau (Boost.Asio) intégré en standard également. Une proposition a été faite.
Bref, si on se renseigne au bon endroit, on peut développer du code C++ pour une quantité impressionnante de plateformes (un code utilisant Qt même pour le GUI passe tel quel sur de plus en plus de portables, par exemple), avec l'efficacité, sans avoir à se trimballer des pointeurs partout (depuis des années, on voit les pointeurs partout comme une mauvaise pratique du C++, on parvient enfin à faire comprendre aux autres que le C++ moderne est un langage qui n'a plus tant de choses que ça de communes avec le C), à gérer la mémoire à la main, etc. Et des bibliothèques comme Boost ou Qt fournissent une quantité énorme d'outils, du GUI au réseau, du Multithreading à la métaprogrammation, de la manipulation avancée de flux à l'intéraction avec des BDD, etc ...
Bref, beaucoup de gens évoluent dans leur langage de prédilection sans ouvrir les yeux sur, par exemple, l'évolution du monde C++. Et ils se retrouvent donc à ressortir des arguments qui datent de 10 ans. Je le sais car je m'amuse à faire la même chose pour Java(pour plaisanter)
C'est vrai c'est un peu fort de café avec boost et qt il y a vraiment une grande différence avec le c++ d'antan.
je n'ai encore pas testé qt ni boost pour voir le niveau de difficulté pour configurer un projet et explorer cela sera probablement intéressant
Ils sont très simples à installer (paquets linux / installateurs pour VC++ / compilation très facile à mettre en oeuvre).C'est vrai c'est un peu fort de café avec boost et qt il y a vraiment une grande différence avec le c++ d'antan.
je n'ai encore pas testé qt ni boost pour voir le niveau de difficulté pour configurer un projet et explorer cela sera probablement intéressant
Enfin, c'était juste pour donner une image plus proche du C++ d'aujourd'hui que ce qui était évoqué dans les précédents posts, après je ne nie absolument pas les qualités de C# ou Java
De toutes façons, la rapidité d'un programme, c'est 20% le matériel, 20% le langage, et 60% l'algo... C'est "empirique", mais c'est souvent très vrai.
On peut de toutes façons distinguer trois types de langages :
- Interprétés,
- Managés / pseudo-code,
- Natifs.
Les langages interprétés (Python, PHP, Ruby, LUA, Javascript, ...) nécessitent un interpréteur pour fonctionner (si, si, j'vous assure !), et souvent uniquement un interpréteur, mais offrent alors une portabilité colossale... La plupart des interpréteurs sont en ligne de commande, et peuvent être compilés sur quasiment n'importe quel système existant.
De plus, ils permettent des choses difficilement accessibles aux autres langages, comme la modification de code à la volée et l'auto-modification des programmes.
Inconvénient, ils sont souvent très lents... Dans le cadre d'un séquenceur / système de contrôle, ça n'a aucune importance. Si c'est pour du calcul lourd, c'est plus que rédhibitoire. Certains de ces langages sont "améliorés" en terme de vitesse d'exécution via une "compilation" à la volée lors de la première exécution (PHP notamment est plutôt efficace à ce sujet).
Autre inconvénient, les erreurs de syntaxe ne sont pas forcément détectées au lancement du programme, parfois c'est lorsque l'on arrive sur la ligne fautive uniquement (voire avec des valeurs particulières en plus), ce qui rend le test extensif de tels programmes assez pénible.
Les langages managés / en pseudo-code (.NET, inclus C# bien sûr, et Java) sont nettement plus véloces que les langages interprétés, par contre ils nécessitent un compilateur, un débugger, un IDE / gestionnaire de projets, bref toute une chaîne de développement. Leur portabilité est limitée à celle du framework qui les soutient (JDK/JRE, .NET) : si le framework existe, les programmes pourront être portés. Sinon, ça risque d'être coton, voire infaisable sans l'aide de la société éditrice. Avantage, par contre, si le framework existe, le programme n'a pas besoin d'être recompilé pour être utilisé sur une autre plate-forme matérielle.
Là aussi, une compilation "native" du pseudo-code est en général faite à la première exécution, pour accélérer le traitement... Cela ne résoud pas tout, hélas.
Enfin, les langages natifs, les plus "lourds" à gérer, produisent du code directement exécutable par le processeur, et sont compilés pour un couple processeur / système d'exploitation "figé". Un exécutable C compilé pour PowerPC / Linux ne fonctionnera JAMAIS tel quel sur une machine Windows / x86... Le programme devra être recompilé impérativement. De plus, le code binaire produit n'est pas le même en fonction du compilateur, et encore moins en fonction du langage source. Le débuggage peut s'avérer difficile et fastidieux en fonction des optimisations du compilateur, voire dans certains cas quasi-impossible.
Par contre, c'est le seul moyen d'obtenir des performances maximales (ou presque), en fonction du langage utilisé toutefois, et normalement déployable sur n'importe quelle plate-forme compatible avec simplement un "jeu" de librairies dynamiques (runtimes) pour certaines applications.
Par exemple, en considérant à chaque fois un matériel identique et des algos optimisés au quart de poil, on a souvent le classement suivant pour les langages les plus connus : Assembleur < C < C++ < Pascal/Delphi < ADA
Après, il faut voir aussi la vitesse de développement avec chacun de ces langages : faire un truc qui ne crashe pas en assembleur, ça peut devenir vite une prise de tête colossale... En ADA, par contre, c'est plutôt "si ça compile, ça marche", vu la rigueur colossale du langage au niveau de la phase lexicale/syntaxique...
Cela ne change pas qu'entre un programme en C, avec un bon algo, et son équivalent Java avec un algo tout aussi optimisé, la différence de performances sera réelle, mais pas forcément aussi énorme qu'on pourrait le croire (hors calculs lourds, faut pas pousser non plus). Par contre, la vitesse de développement avec un langage de très haut niveau est bien plus réduite qu'avec un langage "bas niveau".
De même, en restant dans le domaine d'un "lourd" du domaine, C++ : entre un programme C++ "brut", où tout est développé / optimisé "à la main", et un programme C++ écrit en utilisant intensivement les templates, la STL et des API comme QT, le résultat final est là aussi clair et net : la version "à la barbare" est plus rapide (à optimisation d'algo égale, bien entendu), mais la version "soutenue" par des librairies de haut niveau a par contre pris deux fois moins de temps (au moins !!) à être écrite...
Quant à la perte de performances, même si elle est toujours mesurable, c'est parfois bien moins de 1% de différence si l'on n'est pas en train d'écrire une application de calcul lourd et/ou brassant d'énormes quantités de données...
Si c'est pour faire une application à usage unique / interne, une faisabilité, ou encore un outil de test, ou encore quelque chose de souvent modifié, il faut sérieusement se pencher sur la question du temps de développement... Et envisager les langages interprétés.
Si c'est pour quelque chose ne devant pas être touché, devant être rapide, diffusé largement, etc. alors les langages natifs sont à préférer.
Si cela ne doit pas être touché, diffusé largement mais que la rapidité d'exécution n'est pas cruciale, les langages managés sont l'idéal.
Comme dans presque tous les domaines de l'informatique, le choix du langage, c'est surtout une question de besoins et de contraintes de développement...
Tout-à-fait d'accord avec Mac Lak
La réponse de Mac Lak est parfaite et précise bien les 3 types de technologies de développement d'application (interpréteur, pseudo-code managé, et compilation native) et leurs spécifités et limites.
J'ai juste un petit bémol d'étonnement sur la chaine comparative de la vitesse d'exécution qu'il nous propose pour les langages compilés:
Assembleur < C < C++ < Pascal/Delphi < ADA
En particulier comment justifie-t-il C < C++ et surtout C++ < Pascal/Delphi
Pour C < C++ je peux encore admettre une infime différence due aux indirections supplémentaires qu'induisent l'utilisation d'objets polymorphiques, en particulier lors des appels de méthodes virtuelles, mais en revanche comment justifier la différence C++ < Delphi, attendu que ces deux langages sont de technologies comparables, ne se différenciant essentiellement que par le choix de la syntaxe issue de C ou issue de Pascal. En ce qui me concerne je n'ai pas pratiqué le C++, j'ai développé longtemps sous Delphi avant de rejoinre le monde du pseudo code managé de C# .Net. Donc je suis mal placé pour véritablement juger de manière neutre et pragmatique d'une éventuelle différence d'efficacité fondamentale au bénéfice de C++ par rapport à l'excellent compilateur Delphi (et de ses optimisations du code généré) de feu Borland repris par Embarcadero. Je serais intéressé de connaitre les arguments qui permettent à Mac Lak de justifier son affirmation comparative.
Sinon, encore une fois son résumé est excellent.
C'est un beau déterrage de thread (presque 4 ans depuis le message précédent !), mais il tombe à pic : Microsoft vient d'annoncer .NET native, qui ambitionne de donner aux applications .NET les performances de C++
salut Tomlev c'est une nouvelle incroyable,merci pour l'info et curieux que cela ne suscite pas plus de réaction..
il n'y aura plus d'intérêt à programmer en C++ alors
Mat ! M'enfin... On est pas vendredi !
non mais faut bien alimenter les discussions
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.
Répondre avec citation
Partager