IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

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

Langages de programmation Discussion :

C# est il aussi performant que C++ ? C# est il plus performant que Visual Basic 6 ?


Sujet :

Langages de programmation

  1. #21
    Alp
    Alp est déconnecté
    Expert éminent sénior

    Avatar de Alp
    Homme Profil pro
    Inscrit en
    Juin 2005
    Messages
    8 575
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 35
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations forums :
    Inscription : Juin 2005
    Messages : 8 575
    Points : 11 860
    Points
    11 860
    Par défaut
    Citation Envoyé par aityahia Voir le message
    par contre un bon langage est celui avec lequel on peut offrir a l'utilisateur plus de fonctionnalités en un laps de temps plus court, c'est le cas de C# avec le Framework .NET.
    a+
    Et de C++ avec des frameworks qui s'imposent presque en standard.

  2. #22
    Expert éminent sénior
    Avatar de Mat.M
    Profil pro
    Développeur informatique
    Inscrit en
    Novembre 2006
    Messages
    8 352
    Détails du profil
    Informations personnelles :
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : Novembre 2006
    Messages : 8 352
    Points : 20 359
    Points
    20 359
    Par défaut
    Citation Envoyé par jejerome Voir le message
    En particulier : le langage de programmation C# permet-il de réaliser des applications plus plus performantes que feu Visual Basic 6 ?
    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.

  3. #23
    Membre Expert

    Homme Profil pro
    Ingénieur R&D
    Inscrit en
    Juin 2003
    Messages
    4 506
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Ingénieur R&D
    Secteur : Industrie

    Informations forums :
    Inscription : Juin 2003
    Messages : 4 506
    Points : 5 724
    Points
    5 724
    Par défaut
    Citation Envoyé par Alp Voir le message
    Et de C++ avec des frameworks qui s'imposent presque en standard.
    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
    " Dis ce que tu veux qui insulte mon honneur car mon silence sera la réponse au mesquin.
    Je ne manque pas de réponse mais : il ne convient pas aux lions de répondre aux chiens ! " [Ash-Shafi'i ]

  4. #24
    Alp
    Alp est déconnecté
    Expert éminent sénior

    Avatar de Alp
    Homme Profil pro
    Inscrit en
    Juin 2005
    Messages
    8 575
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 35
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations forums :
    Inscription : Juin 2005
    Messages : 8 575
    Points : 11 860
    Points
    11 860
    Par défaut
    Citation Envoyé par hegros Voir le message
    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.
    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)

  5. #25
    Membre Expert

    Homme Profil pro
    Ingénieur R&D
    Inscrit en
    Juin 2003
    Messages
    4 506
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Ingénieur R&D
    Secteur : Industrie

    Informations forums :
    Inscription : Juin 2003
    Messages : 4 506
    Points : 5 724
    Points
    5 724
    Par défaut
    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
    " Dis ce que tu veux qui insulte mon honneur car mon silence sera la réponse au mesquin.
    Je ne manque pas de réponse mais : il ne convient pas aux lions de répondre aux chiens ! " [Ash-Shafi'i ]

  6. #26
    Alp
    Alp est déconnecté
    Expert éminent sénior

    Avatar de Alp
    Homme Profil pro
    Inscrit en
    Juin 2005
    Messages
    8 575
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 35
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations forums :
    Inscription : Juin 2005
    Messages : 8 575
    Points : 11 860
    Points
    11 860
    Par défaut
    Citation Envoyé par hegros Voir le message
    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).

    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

  7. #27
    Inactif  
    Avatar de Mac LAK
    Profil pro
    Inscrit en
    Octobre 2004
    Messages
    3 893
    Détails du profil
    Informations personnelles :
    Âge : 49
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations forums :
    Inscription : Octobre 2004
    Messages : 3 893
    Points : 4 846
    Points
    4 846
    Par défaut
    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...
    Mac LAK.
    ___________________________________________________
    Ne prenez pas la vie trop au sérieux, de toutes façons, vous n'en sortirez pas vivant.

    Sources et composants Delphi sur mon site, L'antre du Lak.
    Pas de question technique par MP : posez-la dans un nouveau sujet, sur le forum adéquat.

    Rejoignez-nous sur : Serveur de fichiers [NAS] Le Tableau de bord projets Le groupe de travail ICMO

  8. #28
    Nouveau Candidat au Club
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Avril 2014
    Messages
    1
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Suisse

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Industrie

    Informations forums :
    Inscription : Avril 2014
    Messages : 1
    Points : 1
    Points
    1
    Par défaut 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.

  9. #29
    Rédacteur/Modérateur


    Homme Profil pro
    Développeur .NET
    Inscrit en
    Février 2004
    Messages
    19 875
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur .NET
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Février 2004
    Messages : 19 875
    Points : 39 749
    Points
    39 749
    Par défaut
    Citation Envoyé par ChipRaptor Voir le message
    ...
    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++

  10. #30
    Expert éminent sénior
    Avatar de Mat.M
    Profil pro
    Développeur informatique
    Inscrit en
    Novembre 2006
    Messages
    8 352
    Détails du profil
    Informations personnelles :
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : Novembre 2006
    Messages : 8 352
    Points : 20 359
    Points
    20 359
    Par défaut
    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

  11. #31
    Membre émérite Avatar de Cirrus Minor
    Homme Profil pro
    Développeur .NET
    Inscrit en
    Mars 2014
    Messages
    953
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Allemagne

    Informations professionnelles :
    Activité : Développeur .NET

    Informations forums :
    Inscription : Mars 2014
    Messages : 953
    Points : 2 610
    Points
    2 610
    Par défaut
    Mat ! M'enfin... On est pas vendredi !

  12. #32
    Expert éminent sénior
    Avatar de Mat.M
    Profil pro
    Développeur informatique
    Inscrit en
    Novembre 2006
    Messages
    8 352
    Détails du profil
    Informations personnelles :
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : Novembre 2006
    Messages : 8 352
    Points : 20 359
    Points
    20 359
    Par défaut
    Citation Envoyé par Cirrus Minor Voir le message
    Mat ! M'enfin... On est pas vendredi !
    non mais faut bien alimenter les discussions

Discussions similaires

  1. Réponses: 23
    Dernier message: 15/12/2011, 22h48
  2. Réponses: 11
    Dernier message: 03/09/2010, 11h22
  3. "Les Beatles sont plus populaires que Jesus" : c'est Google qui le dit !
    Par Katleen Erna dans le forum Humour Informatique
    Réponses: 3
    Dernier message: 24/09/2009, 13h12
  4. Réponses: 0
    Dernier message: 23/09/2009, 03h59
  5. Document imprimé - plus général que cela c'est pas possible
    Par pjmorce dans le forum Langages de programmation
    Réponses: 2
    Dernier message: 11/01/2009, 00h29

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo