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

C++ Discussion :

[debat] Le mot clef const


Sujet :

C++

  1. #61
    yan
    yan est déconnecté
    Rédacteur
    Avatar de yan
    Homme Profil pro
    Ingénieur expert
    Inscrit en
    Mars 2004
    Messages
    10 033
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : France, Ille et Vilaine (Bretagne)

    Informations professionnelles :
    Activité : Ingénieur expert
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Mars 2004
    Messages : 10 033
    Points : 13 968
    Points
    13 968
    Par défaut
    Citation Envoyé par Dr Dédé Voir le message
    Mais dans les faits, la qualité et la fiabilité des outils C++ sont inférieurs, parce que C++ est trop complexe (particulièrement à cause du préprocesseur).
    comme????

  2. #62
    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 screetch Voir le message
    j'y pense parfois
    Haskell Tu regretteras vraiment pas le voyage.

    Citation Envoyé par poukill Voir le message
    Pour le temps de compilation, il est vrai que l'utilisation systématiques des déclarations dans les .h, et les include dans les .cpp sont un bon début.
    Personnellement, sous gcc avec l'option -j 4, je gagne un facteur 2.5 encore en compilation.

    Sinon, je crois aussi que LLVM apportera un temps de compil beaucoup plus faible dans le futur !
    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 :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
     
    blabla< <int > var;
               ^
    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.

    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.

  3. #63
    Invité
    Invité(e)
    Par défaut
    Citation Envoyé par Alp Voir le message
    avec par exemple des "^" pour indiquer à quel endroit l'erreur se situe
    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, ...)

  4. #64
    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 Joe Dralliam Voir le message
    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 ?
    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.

  5. #65
    Membre chevronné
    Avatar de Joel F
    Homme Profil pro
    Chercheur en informatique
    Inscrit en
    Septembre 2002
    Messages
    918
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Chercheur en informatique
    Secteur : Service public

    Informations forums :
    Inscription : Septembre 2002
    Messages : 918
    Points : 1 921
    Points
    1 921
    Par défaut
    Citation Envoyé par Joe Dralliam Voir le message
    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 ?
    Tu preferes quoi:

    no such operator+ line 24:
    a + b + c + foo(z)

    ou

    no such operator+ line 24:
    a + b + c + foo(z)
    -------^

    ??

  6. #66
    Invité
    Invité(e)
    Par défaut
    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à...)

  7. #67
    Membre régulier

    Inscrit en
    Octobre 2010
    Messages
    50
    Détails du profil
    Informations forums :
    Inscription : Octobre 2010
    Messages : 50
    Points : 70
    Points
    70
    Par défaut
    Citation Envoyé par Davidbrcz Voir le message
    Je connais plusieurs personnes qui bossent dans des domaines très divers (jeux vidéos, embarqué critique, calcul numérique haute performance) et qui utilisent tous le C++. Tous ont des besoins différents avec des contraintes différentes, je vois mal comment le standard pourrait tous les combler sans que ca devienne un gros foutoir ou qu'ils soient obligés d'aller voir ailleurs pour récupérer un outils que le langage n'offrirait pas. Etant donné que les outils offerts par Java/C#/... sembler contenter tout le monde, est ce que ca ne veut pas dire qu'ils ne sont destinés qu'à un seul type (au sens large) de projet ? Je ne prendrais pas les paris car j'ai peur de la réponse.
    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é.

    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.
    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.

    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.
    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.

    On a les fichiers d'en tête pour ca [fournir une vue d'ensemble] plus tous les outils externes qui peuvent exister à coté.
    ...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.

    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.
    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.

    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.)

    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 ?
    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.

    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().
    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.

    Citation Envoyé par yan
    Citation Envoyé par Dr Dédé
    Mais dans les faits, la qualité et la fiabilité des outils C++ sont inférieurs, parce que C++ est trop complexe (particulièrement à cause du préprocesseur).
    comme????
    Comme les outils que je mentionnais dans la phrase suivant celle que tu citais.

  8. #68
    gl
    gl est déconnecté
    Rédacteur

    Homme Profil pro
    Inscrit en
    Juin 2002
    Messages
    2 165
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 45
    Localisation : France, Isère (Rhône Alpes)

    Informations forums :
    Inscription : Juin 2002
    Messages : 2 165
    Points : 4 637
    Points
    4 637
    Par défaut
    Citation Envoyé par Dr Dédé Voir le message
    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é.
    Certes, je suis d'accord qu'il est préférable d'utiliser l'outil le plus adapté.

    Mais pour une application PC, C# ou Java sont-ils vraiment mieux adapté que C++ dans le cas général ?
    Et dans le cas d'un développeur connaissant C++ mais pas C# ?

  9. #69
    Membre régulier

    Inscrit en
    Octobre 2010
    Messages
    50
    Détails du profil
    Informations forums :
    Inscription : Octobre 2010
    Messages : 50
    Points : 70
    Points
    70
    Par défaut
    Citation Envoyé par gl Voir le message
    Certes, je suis d'accord qu'il est préférable d'utiliser l'outil le plus adapté.

    Mais pour une application PC, C# ou Java sont-ils vraiment mieux adapté que C++ dans le cas général ?
    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++.

    Et dans le cas d'un développeur connaissant C++ mais pas 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++.

  10. #70
    Débutant
    Profil pro
    Inscrit en
    Mai 2006
    Messages
    688
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mai 2006
    Messages : 688
    Points : 176
    Points
    176
    Par défaut
    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

  11. #71
    Membre chevronné
    Avatar de Joel F
    Homme Profil pro
    Chercheur en informatique
    Inscrit en
    Septembre 2002
    Messages
    918
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Chercheur en informatique
    Secteur : Service public

    Informations forums :
    Inscription : Septembre 2002
    Messages : 918
    Points : 1 921
    Points
    1 921
    Par défaut
    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 :€

  12. #72
    yan
    yan est déconnecté
    Rédacteur
    Avatar de yan
    Homme Profil pro
    Ingénieur expert
    Inscrit en
    Mars 2004
    Messages
    10 033
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : France, Ille et Vilaine (Bretagne)

    Informations professionnelles :
    Activité : Ingénieur expert
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Mars 2004
    Messages : 10 033
    Points : 13 968
    Points
    13 968
    Par défaut
    Citation Envoyé par Dr Dédé Voir le message
    Comme les outils que je mentionnais dans la phrase suivant celle que tu citais.

    mouais tu généralise facilement toi...

    Au finale tu cherche à prouver quoi dans ta discution???

  13. #73
    Membre régulier

    Inscrit en
    Octobre 2010
    Messages
    50
    Détails du profil
    Informations forums :
    Inscription : Octobre 2010
    Messages : 50
    Points : 70
    Points
    70
    Par défaut
    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.

    Citation Envoyé par yen
    mouais tu généralise facilement toi...
    À ce que je sache, Visual AssistX est le meilleur plugin C++. Tu connais mieux?

    Citation Envoyé par yen
    Au finale tu cherche à prouver quoi dans ta discution?
    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.

  14. #74
    zul
    zul est déconnecté
    Membre éclairé Avatar de zul
    Profil pro
    Inscrit en
    Juin 2002
    Messages
    498
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juin 2002
    Messages : 498
    Points : 699
    Points
    699
    Par défaut
    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 ).

  15. #75
    Membre chevronné
    Avatar de Goten
    Profil pro
    Inscrit en
    Juillet 2008
    Messages
    1 580
    Détails du profil
    Informations personnelles :
    Âge : 33
    Localisation : France

    Informations forums :
    Inscription : Juillet 2008
    Messages : 1 580
    Points : 2 205
    Points
    2 205
    Par défaut
    Citation Envoyé par Dr Dédé Voir le message
    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 .
    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).
    "Hardcoded types are to generic code what magic constants are to regular code." --A. Alexandrescu

  16. #76
    screetch
    Invité(e)
    Par défaut
    Citation Envoyé par Dr Dédé Voir le message
    juste à échanger des idées.
    echanger, hein...

  17. #77
    gl
    gl est déconnecté
    Rédacteur

    Homme Profil pro
    Inscrit en
    Juin 2002
    Messages
    2 165
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 45
    Localisation : France, Isère (Rhône Alpes)

    Informations forums :
    Inscription : Juin 2002
    Messages : 2 165
    Points : 4 637
    Points
    4 637
    Par défaut
    Citation Envoyé par Dr Dédé Voir le message
    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
    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.

    Citation Envoyé par Dr Dédé Voir le message
    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 ».
    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.

    Citation Envoyé par Dr Dédé Voir le message
    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.
    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++".

  18. #78
    Membre chevronné
    Avatar de Joel F
    Homme Profil pro
    Chercheur en informatique
    Inscrit en
    Septembre 2002
    Messages
    918
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Chercheur en informatique
    Secteur : Service public

    Informations forums :
    Inscription : Septembre 2002
    Messages : 918
    Points : 1 921
    Points
    1 921
    Par défaut
    Citation Envoyé par Dr Dédé Voir le message
    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.
    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.

  19. #79
    yan
    yan est déconnecté
    Rédacteur
    Avatar de yan
    Homme Profil pro
    Ingénieur expert
    Inscrit en
    Mars 2004
    Messages
    10 033
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : France, Ille et Vilaine (Bretagne)

    Informations professionnelles :
    Activité : Ingénieur expert
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Mars 2004
    Messages : 10 033
    Points : 13 968
    Points
    13 968
    Par défaut
    Citation Envoyé par Dr Dédé Voir le message
    À ce que je sache, Visual AssistX est le meilleur plugin C++. Tu connais mieux?
    Tu veux un plugin pour faire quoi?
    Comparer un seul outils est dire que
    qualité et la fiabilité des outils C++ sont inférieurs
    me parait bien extrême.


    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...

  20. #80
    Membre régulier

    Inscrit en
    Octobre 2010
    Messages
    50
    Détails du profil
    Informations forums :
    Inscription : Octobre 2010
    Messages : 50
    Points : 70
    Points
    70
    Par défaut
    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.

    Tu veux un plugin pour faire quoi?
    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.xml

    Par exemple, j'ai une classe qui propose une interface listener pour envoyer des données.
    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++.

    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.
    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.)

    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.
    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.

    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 comprends bien ton point de vue et j'apprécie ton discernement.

    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.

    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.
    Reste que WPF est disponible en C# et pas en C++. Qt, lui, a des bindings pour beaucoup de langages incluant C#.

Discussions similaires

  1. Intérêt de mot clef const dans une méthode
    Par teddyalbina dans le forum C#
    Réponses: 3
    Dernier message: 05/03/2012, 15h22
  2. question sur le mot clef const
    Par elmcherqui dans le forum C++
    Réponses: 3
    Dernier message: 08/07/2008, 09h42
  3. Réponses: 14
    Dernier message: 25/10/2007, 16h00
  4. [Debat] le mot-clef "friend", est-ce si "mal"?
    Par 5:35pm dans le forum C++
    Réponses: 42
    Dernier message: 23/08/2007, 20h54

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