+ Répondre à la discussion Actualité déjà publiée
Page 1 sur 2 12 DernièreDernière
  1. #1
    Rédacteur/Modérateur
    Avatar de JolyLoic
    Homme Profil pro
    Développeur informatique
    Inscrit en
    août 2004
    Messages
    5 351
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : France, Yvelines (Île de France)

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

    Informations forums :
    Inscription : août 2004
    Messages : 5 351
    Points : 14 843
    Points
    14 843

    Par défaut Cinq mythes courants sur le C++ (traduction d'un article de Bjarne Stroustrup)

    Bonjour à tous,

    Je viens de publier une traduction d'un article de Bjarne Stroustrup discutant de Cinq mythes courants sur le C++.

    Je trouve que cet article est intéressant non seulement pour ceux qui débutent en C++, mais aussi pour ceux qui connaissent un langage qui fait partie de la même famille (C, C#, Java...) et qui voudraient avoir une idée de ce qui caractérise le C++, de ce qui lui est spécifique.

    N'hésitez pas à laisser vos commentaires !

    PS : Suite à l'article et aux nombreuses remarques qu'il a suscitées, Bjarne a aussi publié une postface (pas encore traduite).
    Ma session aux Microsoft TechDays 2013 : Développer en natif avec C++11.
    Celle des Microsoft TechDays 2014 : Bonnes pratiques pour apprivoiser le C++11 avec Visual C++
    Et celle des Microsoft TechDays 2015 : Visual C++ 2015 : voyage à la découverte d'un nouveau monde

  2. #2
    Nouveau membre du Club
    Profil pro
    Inscrit en
    juillet 2009
    Messages
    16
    Détails du profil
    Informations personnelles :
    Localisation : France, Ille et Vilaine (Bretagne)

    Informations forums :
    Inscription : juillet 2009
    Messages : 16
    Points : 26
    Points
    26

    Par défaut

    Bonjour et merci pour cette traduction, l'article est intéressant.

    Je n'ai pas fini de le lire mais je pose une question. A plusieurs reprise les exemples de code donnés utilisent des accolades {} là où j'aurais naturellement mis des parenthèses ().

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    void user2()
    {
      Filter flt {"books","authors"};
      unique_ptr<Filter> p {new Filter{"novels","favorites"}};
      // on utilise flt et *p
    }
    Dans cet exemple, je pensais qu'il était impossible d'utiliser des accolades pour passer les 2 arguments au constructeur de Filter. S'agit-il d'un des standard de C++ ou d'une erreur de recopie/traduction ?

  3. #3
    Expert éminent
    Homme Profil pro
    Développeur informatique
    Inscrit en
    février 2005
    Messages
    4 226
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 45
    Localisation : France, Val de Marne (Île de France)

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

    Informations forums :
    Inscription : février 2005
    Messages : 4 226
    Points : 9 141
    Points
    9 141

    Par défaut

    Il s'agit de "nouvelles" notations introduites avec le C++11, en 2011.

  4. #4
    Rédacteur/Modérateur
    Avatar de JolyLoic
    Homme Profil pro
    Développeur informatique
    Inscrit en
    août 2004
    Messages
    5 351
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : France, Yvelines (Île de France)

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

    Informations forums :
    Inscription : août 2004
    Messages : 5 351
    Points : 14 843
    Points
    14 843

    Par défaut

    C'est possible à partir du C++11, et ça permet une syntaxe d'initialisation plus uniforme dans les différents cas (même si les autres syntaxes d'initialisation restent possibles pour compatibilité, voire même indispensables dans certains cas). Une des nouveautés appréciables apportées par cette syntaxe est la capacité d'initialiser des collections :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    map<string, string> m {{"Hello", "Bonjour"}, {"World", "Monde"}};
    En tant que promoteur principale de cette syntaxe, Bjarne l'utilise systématiquement dans ses articles. Et l'idée est que si on souhaite n'apprendre qu'une seule syntaxe à quelqu'un, autant apprendre celle là.
    Ma session aux Microsoft TechDays 2013 : Développer en natif avec C++11.
    Celle des Microsoft TechDays 2014 : Bonnes pratiques pour apprivoiser le C++11 avec Visual C++
    Et celle des Microsoft TechDays 2015 : Visual C++ 2015 : voyage à la découverte d'un nouveau monde

  5. #5
    Nouveau membre du Club
    Profil pro
    Inscrit en
    juillet 2009
    Messages
    16
    Détails du profil
    Informations personnelles :
    Localisation : France, Ille et Vilaine (Bretagne)

    Informations forums :
    Inscription : juillet 2009
    Messages : 16
    Points : 26
    Points
    26

    Par défaut

    Ok, je connaissais la nouvelle syntaxe pour initialiser un liste en passant toutes les valeurs séparées par des virgules, le tout entre accolades. Mais la possibilité d'utiliser cette syntaxe pour initialiser un objet classique m'avait complètement échappé. Je m'en vais trouver un peu de doc là dessus.
    Merci

  6. #6
    Expert éminent sénior

    Femme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    juin 2007
    Messages
    4 767
    Détails du profil
    Informations personnelles :
    Sexe : Femme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : juin 2007
    Messages : 4 767
    Points : 15 473
    Points
    15 473

    Par défaut

    Un point d'entrée comme un autre, list initialization sur cppreference.com.
    Mes principes de bases du codeur qui veut pouvoir dormir:
    • Une variable de moins est une source d'erreur en moins.
    • Un pointeur de moins est une montagne d'erreurs en moins.
    • Un copier-coller, ça doit se justifier... Deux, c'est un de trop.
    • jamais signifie "sauf si j'ai passé trois jours à prouver que je peux".
    • La plus sotte des questions est celle qu'on ne pose pas.
    Pour faire des graphes, essayez yEd.
    le ter nel est le titre porté par un de mes personnages de jeu de rôle

  7. #7
    Rédacteur/Modérateur

    Avatar de bouye
    Homme Profil pro
    Information Technologies Specialist (Scientific Computing)
    Inscrit en
    août 2005
    Messages
    5 620
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : Nouvelle-Calédonie

    Informations professionnelles :
    Activité : Information Technologies Specialist (Scientific Computing)
    Secteur : Agroalimentaire - Agriculture

    Informations forums :
    Inscription : août 2005
    Messages : 5 620
    Points : 20 175
    Points
    20 175
    Billets dans le blog
    30

    Par défaut

    Mouai, intéressant mais surtout destinés a ceux qui commencent le C++ aujourd'hui et en utilisant des bibliothèques modernes et non pas des vieux machins legacy d'il y a 20+ ans.

    Pour les vieux fossiles comme moi, a l’époque le char* était plus courant que le string, la lib standard C++ était peanuts, et la majorité des libs externes étaient écrites en C ou en C++ C-like. Donc oui ça avait beaucoup beaucoup plus de sens de commencer par C a l'epoque. Mais cela concernait les versions de C++ circa 96-98-01. Évidement c'est moins évident que de commencer directement en C++ '11. Porter l’intégralité d'un programme ou d'un framework pre-existant (donc écrit a l'ancienne) demande des investissements (entre autre dans mon cas la formation de scientifiques et mathématiciens qui développent des modèles) qu'on ne peut pas tout le temps se permettre (ou ne veut pas dans leur cas).

    Pour le reste non, bien que The C++ Programming Language ~ Special Edition de Stroustrup (livre qui, a nouveau, concerne des anciennes versions de C++) trône sur mes étagères derrière moi depuis plus de 10 ans bien que je fasse du C++ assez régulièrement, j'ai toujours une réaction de rejet quand j'essaie de lire la doc d'une classe ou d'une méthode de fonction a 45 (j’exagère) arguments génériques imbriquées dont ni le nom ni la doc ne m'explique clairement ce a quoi ils ou elle servent. Probablement une déformation de faire du Java (que d'aucun trouvent trop verbeux justement a cause des noms trop long et trop explicites). Ceci dit les dernières évolutions de Java 8 font que désormais on peut retrouver cette même complexité de compréhension en utilisant trop de génériques et de lambda pour reduire un bloc de code a une instruction d'une seule ligne donc en gros on a atteint le même niveau.

    Ensuite, n'essaie-t-il pas de prêcher des convertis ? Je veux dire, prenons les sessions vidéo de la dernière conf C++ qui ont été publié ici sur Developpez. Rien que les sessions présentées par Ubisoft sont quand même parlantes : si on veut de la perf brute (et dans le cas d'Ubi de la portabilité sur les plateformes de jeux via leurs framework maison), on fait du C++. Pour eux le C# ne sert que pour les outils middleware qu'ils utilisent en interne ; le produit qui sera publié et vendu sera lui écrit en C++ principalement.
    Merci de penser au tag quand une réponse a été apportée à votre question. Aucune réponse ne sera donnée à des messages privés portant sur des questions d'ordre technique. Les forums sont là pour que vous y postiez publiquement vos problèmes.

    suivez mon blog sur Développez.

    Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the universe trying to produce bigger and better idiots. So far, the universe is winning. ~ Rich Cook

  8. #8
    Membre averti

    Profil pro
    Inscrit en
    décembre 2013
    Messages
    298
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : décembre 2013
    Messages : 298
    Points : 307
    Points
    307

    Par défaut

    Il est évident que les évolutions des langages (ou les nouveaux langages) ne vont pas intéresser ceux qui n'ont pas évolué depuis 20 ans.
    Par contre, ces évolutions ne vont pas intéresser que les débutants, mais également ceux qui ont compris que le coût de mise a niveau de ses connaissances et des projets est largement compensé par les résultats obtenus (efficacité pour écrire des programmes et surtout corriger les problèmes).

    Beaucoup de ceux qui continue de faire du C++ old school ne le font pas parce qu'ils maîtrisent le C++ old school (beaucoup de codes C++ old school sont crades, en particulier sur la gestion des erreurs).
    Il y a pleins de personnes sur ce forum qui travaillent sur du code ancien ou avec des scientifiques, ce n'est pas forcement impossible de faire évoluer les choses.

  9. #9
    Membre habitué
    Homme Profil pro
    Enseignant Chercheur
    Inscrit en
    juillet 2009
    Messages
    96
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Enseignant Chercheur

    Informations forums :
    Inscription : juillet 2009
    Messages : 96
    Points : 174
    Points
    174

    Par défaut

    Merci Loïc pour cette traduction. J'ai trouvé cet article très intéressant.

  10. #10
    Modérateur
    Avatar de Gugelhupf
    Homme Profil pro
    Analyste Programmeur
    Inscrit en
    décembre 2011
    Messages
    1 127
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Analyste Programmeur

    Informations forums :
    Inscription : décembre 2011
    Messages : 1 127
    Points : 2 650
    Points
    2 650
    Billets dans le blog
    12

    Par défaut

    Je suis tout à fait d'accord avec les points cités par Bjarne.

    Pour moi si ces problèmes perdurent, c'est qu'on ne va pas à la source des problèmes, voici quelques facteurs qui font que pour moi on reste dans le passé avec le C++ :
    • Les vielles distributions à l'école avec GCC et C89 (ou G++).
    • Les compilateurs plus récents (je pense à GCC) qui n'activent pas par défaut C++11/14 (ps : en espérant que cela ait changé depuis...)
    • Beaucoup de tutoriel sur internet, mais la plupart sont nuls, on ne montre pas toutes les possibilités offertes par C++11/14 (je pense aux variétés de pointeur intelligent ou aux threads par exemple).


    Autrement l'impression que j'ai eu il y a quelques années lorsque j'apprenais le C++ sur les forums (SdZ principalement à l'époque) est que les gens (peut-être des "vieux") avaient un manque de volonté phénoménal à vouloir partager leurs connaissances (ils ne s'aidaient vraiment entre eux que lorsque les sujets abordés leurs semblaient suffisamment "intéressant"). D'ailleurs j'avais lu quelque part une personne du forum (developpez) avoir eu le même ressenti pour le langage Java à une certaine époque mais que les choses avaient changés depuis l'expansion de C# et PHP pour le web (peut-être la peur de voir sa communauté disparaitre à cause des concurrents). Par contre pour le langage PHP je n'ai jamais eu de mauvais retour, peut-être parce que c'est un langage à la base plus ouvert de par sa simplicité et que la volonté de sa communauté (dont non informaticien) n'est pas de garder le "secret" des connaissances pour eux-même.
    Bien sûr les choses ont beaucoup changé depuis je pense, un problème fréquent rencontré ? Et hop go sur stack.
    Bref c'était mon ressenti, vous pouvez ne pas être d'accord.
    N'hésitez pas à consulter la FAQ Java, lire les cours et tutoriels Java, et à poser vos questions sur les forums d'entraide Java

    Mon profil Developpez | Mon profil Linkedin | Mon site : https://gokan-ekinci.appspot.com

  11. #11
    Expert éminent
    Avatar de Luc Hermitte
    Homme Profil pro
    Développeur informatique
    Inscrit en
    août 2003
    Messages
    5 123
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : août 2003
    Messages : 5 123
    Points : 9 893
    Points
    9 893

    Par défaut

    Citation Envoyé par bouye Voir le message
    Mouai, intéressant mais surtout destinés a ceux qui commencent le C++ aujourd'hui et en utilisant des bibliothèques modernes et non pas des vieux machins legacy d'il y a 20+ ans.
    L'article en lui même vise surtout les "anciens" comme nous, car justement beaucoup n'ont pas encore intégré le fait qu'il y avait des exceptions en C++, ou ne serait-ce ce que les destructeurs peuvent faire pour nous -- là, je suis toujours en C++98/03. Et aussi ceux qui n'ont pas encore eu le temps de regarder, ensuite, ce que les C++11 et 14 apportent.

    Après, il y a certes les problèmes de base vieilles bases de code, et de compilos limités par les distribs linux/windows. Mais cela n'empêche en rien de former les gens à développer dans un C++ plus moderne.

    Citation Envoyé par Gugelhupf Voir le message
    Autrement l'impression que j'ai eu il y a quelques années lorsque j'apprenais le C++ sur les forums (SdZ principalement à l'époque) est que les gens (peut-être des "vieux") avaient un manque de volonté phénoménal à vouloir partager leurs connaissances (ils ne s'aidaient vraiment entre eux que lorsque les sujets abordés leurs semblaient suffisamment "intéressant").
    C'est un phénomène classique. On forme une première fournée de débutants, et petit à petit on leur refile les réponses simples. Si on voit que les questions simples sont pas ou mal traitées, on intervient. Mais il arrive, il est vrai, que l'on finisse par en avoir marre de répondre aux mêmes exos très basiques (car après tout, on ne doit rien à personne quand on répond bénévolement), ou aux questions où les choses deviennent inutilement des usines à gaz (un effet pervers est que l'on ne tient pas à se prendre le choux sur des codes d'autres personnes qui sont à l'ancienne quand on a déjà nos bases de codes à maintenir/moderniser, et de fait on voit une recrudescence de "bashage de profs qui apprennent le C++ old school").
    Cela me fait penser "Hacker guide" d'Eric Raymond qui décrit (entre autres), un phénomène très similaire, IIRC.
    Blog|FAQ C++|FAQ fclc++|FAQ Comeau|FAQ C++lite|FAQ BS|Bons livres sur le C++
    Les MP ne sont pas une hotline. Je ne réponds à aucune question technique par le biais de ce média. Et de toutes façons, ma BAL sur dvpz est pleine...

  12. #12
    Expert éminent sénior

    Avatar de Neckara
    Homme Profil pro
    Étudiant
    Inscrit en
    décembre 2011
    Messages
    6 150
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 24
    Localisation : France, Loire (Rhône Alpes)

    Informations professionnelles :
    Activité : Étudiant
    Secteur : Enseignement

    Informations forums :
    Inscription : décembre 2011
    Messages : 6 150
    Points : 15 991
    Points
    15 991

    Par défaut

    Bonjour,

    Citation Envoyé par JolyLoic Voir le message
    C'est possible à partir du C++11, et ça permet une syntaxe d'initialisation plus uniforme dans les différents cas (même si les autres syntaxes d'initialisation restent possibles pour compatibilité, voire même indispensables dans certains cas). Une des nouveautés appréciables apportées par cette syntaxe est la capacité d'initialiser des collections :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    map<string, string> m {{"Hello", "Bonjour"}, {"World", "Monde"}};
    En tant que promoteur principale de cette syntaxe, Bjarne l'utilise systématiquement dans ses articles. Et l'idée est que si on souhaite n'apprendre qu'une seule syntaxe à quelqu'un, autant apprendre celle là.
    J'avoue que je ne comprend pas vraiment son raisonnement. Comme tu l'as dit :
    même si les autres syntaxes d'initialisation restent possibles pour compatibilité, voire même indispensables dans certains cas
    En effet, si on a :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    class C{
         C( std::initializer_list<int>() values ); // (1)
         C(int taille, int default value = int() ); // (2)
    };
    Alors :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    C(5,5)
    C{5,5}
     
    C(4)
    C{4}
    Ne font pas du tout la même chose, c'est donc, de mon avis, un hérésie de mélanger les deux.
    En effet, si on n'utilise que {}, il y a de fortes chances qu'on ne fasse pas la distinction entre {} et () ce qui sera très préjudiciable par la suite.
    Autant se dire tout de suite : () = constructeur normal et {} = constructeur par liste d'initialisation.

    Imaginons qu'on ai uniquement le constructeur (2) et qu'on utilise des accolades. On décide ensuite d'ajouter le constructeur (1) quelques mois plus tard. Que fait-on par la suite ? On réécrit tout notre code ? On oublie certaines partie et on laisse des {} là où il faudrait maintenant des () ?

    De plus, je ne comprend pas l'argument d'uniformisation, pour moi, c'est encore moins uniforme !
    Pour les initialiseurs, {}
    Pour les autres constructeurs, {} ou () si un initialiseur d'arguments "similaire" existe.
    On dit "chiffrer" pas "crypter" !

    On dit "bibliothèque" pas "librairie" !

    Ma page DVP : http://neckara.developpez.com/

  13. #13
    Membre expert
    Profil pro
    Inscrit en
    mars 2007
    Messages
    1 415
    Détails du profil
    Informations personnelles :
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : mars 2007
    Messages : 1 415
    Points : 3 128
    Points
    3 128

    Par défaut

    Citation Envoyé par Neckara Voir le message
    De plus, je ne comprend pas l'argument d'uniformisation, pour moi, c'est encore moins uniforme !
    C'est plus uniforme car la même syntaxe est utilisée pour constructeurs par initializer_list et les constructeurs classiques. C'est le seul moyen pour écrire des constructions de collections imbriquées. L'ancienne syntaxe doit être conservée car la rétro-compatibilité est une feature en C++.

    Citation Envoyé par Neckara Voir le message
    Imaginons qu'on ai uniquement le constructeur (2) et qu'on utilise des accolades. On décide ensuite d'ajouter le constructeur (1) quelques mois plus tard. Que fait-on par la suite ? On réécrit tout notre code ? On oublie certaines partie et on laisse des {} là où il faudrait maintenant des () ?
    Pour cette même raison, si tu conçois ton code de sorte à ce que n'utiliser que la notation {} donne un code valide, le problème ne se posera pas. Et s'il se pose, si tu utilises la différence ce notation pour lever l'ambiguité, il y a un risque de mal utiliser le code car les deux syntaxes sont quand même disponibles. Oui, ça peut introduire des confusions, c'est un défaut notable, mais que perso je considère acceptable au regard du gain.
    Find me on github

  14. #14
    Expert éminent sénior

    Avatar de Neckara
    Homme Profil pro
    Étudiant
    Inscrit en
    décembre 2011
    Messages
    6 150
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 24
    Localisation : France, Loire (Rhône Alpes)

    Informations professionnelles :
    Activité : Étudiant
    Secteur : Enseignement

    Informations forums :
    Inscription : décembre 2011
    Messages : 6 150
    Points : 15 991
    Points
    15 991

    Par défaut

    Citation Envoyé par jblecanard Voir le message
    C'est plus uniforme car la même syntaxe est utilisée pour constructeurs par initializer_list et les constructeurs classiques.
    Sauf dans le cas où on a les deux (initializer_list et les constructeurs classiques) possibles pour les même arguments.
    Imagine aussi, tu veux appeler C(int, int).
    Tu vas mettre des {} par habitude. Grossière erreur, il faut au préalable et systématiquement vérifier si ta classe C ne possède pas de constructeur avec initializer_list pouvant "matcher".
    Je ne pense pas que ce soit vraiment pratique pour l'utilisateur, et pire encore pour le débutant.
    Le pauvre qui n'arrivera pas à comprendre pourquoi sa classe n'est pas initialisée comme il le souhaiterait .

    Je trouve qu'il est plus simple de lui dire "utilise ()".
    Puis plus tard, quand on voit les initializer_list, lui dire "utilise {} pour les initializer_list".

    Plutôt que de lui dire "utilise {}" et quand il a pris l'habitude d'utiliser les {}, on lui montre les initializer_list et on lui dit, "on t'as menti, en fait c'est pas toujours {}, parfois faut utiliser ()".
    Ou alors travailler en C++90 sur des projets et en C++11 sur d'autres, passer de () à {} et inversement, cela peut vite devenir soûlant.

    Je ne parle pas de la configuration des IDE pour les auto-complétion et extraits de codes…

    Et s'il se pose, si tu utilises la différence ce notation pour lever l'ambiguité
    Donc on doit modifier tout code qui utilise notre classe ?
    Cela va à l'encontre des bon principes de programmations.

    Encore pire si notre classe fait partie d'une bibliothèque utilisée par d'autres…

    perso je considère acceptable au regard du gain.
    J'ai, personnellement du mal à voir le gain apporté par l'utilisation de {} pour le constructeur au lieu de ().
    On dit "chiffrer" pas "crypter" !

    On dit "bibliothèque" pas "librairie" !

    Ma page DVP : http://neckara.developpez.com/

  15. #15
    Membre averti

    Profil pro
    Inscrit en
    décembre 2013
    Messages
    298
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : décembre 2013
    Messages : 298
    Points : 307
    Points
    307

    Par défaut

    @Neckara
    Je te conseille très fortement la lecture de Effective Moderne C++, de Scott Meyers

    Pour la confusion entre () et {} lorsque tu as un initializer_list constructor est effectivement problématique (Scott Meyers parle même d'une erreur de conception de vector).
    Donc si tu as une classe qui n'a pas de constructeur par liste, tu ne dois surtout pas l'ajouter dans un second temps. Sinon, comme tu l'as dit, cela peut provoquer un changement de comportement du code, qui serait indétectable et donc galère à corriger.
    Le problème ne se pose pas si on passe d'un code C++03 et qu'on compile avec un compilateur C++11 (qui ajoute donc par exemple std::vector(initializer_list) ) puisque l'ancien code n'utilisait pas les {}

    En termes d'enseignements, cela veut dire effectivement que l'on ne peut pas dire "il faut utiliser {}" ou "il faut utiliser ()". Cela dépend. Et c'est donc plus complique à expliquer.
    Il faut probablement éviter d'utiliser les initializer_list constructor, excepté dans les rares cas de création d'une classe "conteneur" (type vector, list, etc). Dans ce cas, on peut considérer que l'utilisateur sait qu'il y a une différence entre () et {}, du fait que la STL utilise aussi cette approche.

    Pour l'utilisation de "uniform initialisation", cela vient du fait qu'en C++03, il n'est pas toujours possible d'utiliser = ou () pour initialiser une variable. Alors que {} sera toujours utilisable :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
     
    int x(0); // ok
    int x = 0; // ok
    int x{0}; // ok
     
    int x(); // problème
    // pas de default initialization avec =
    int x{}; // ok
     
    int x[] = { 1, 2, 3}; // ok
    vector<int> x = { 1, 2, 3}; // ok en C++11, pas en C++03
     
    class A {
      int x(0); // erreur
      int x = 0; // ok
      int x{0}; // ok
    };
     
    // class non copiable
    atomic<int> x(0); // ok
    atomic<int> x = 0; // erreur
    atomic<int> x{0}; // ok
    Il y a d'autres problèmes avec () et {}, en particulier concernant la déduction automatique des types avec auto ou dans les templates, ce qui influence comment on doit écrire et appeler ce type de fonction. Cf le livre pour les détails

  16. #16
    Expert éminent sénior

    Avatar de Neckara
    Homme Profil pro
    Étudiant
    Inscrit en
    décembre 2011
    Messages
    6 150
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 24
    Localisation : France, Loire (Rhône Alpes)

    Informations professionnelles :
    Activité : Étudiant
    Secteur : Enseignement

    Informations forums :
    Inscription : décembre 2011
    Messages : 6 150
    Points : 15 991
    Points
    15 991

    Par défaut

    Citation Envoyé par mintho carmo Voir le message
    Je te conseille très fortement la lecture de Effective Moderne C++, de Scott Meyers
    Le problème, c'est que je suis dans une période où je n'ai pas forcément beaucoup de temps .


    Pour la confusion entre () et {} lorsque tu as un initializer_list constructor est effectivement problématique (Scott Meyers parle même d'une erreur de conception de vector). Donc si tu as une classe qui n'a pas de constructeur par liste, tu ne dois surtout pas l'ajouter dans un second temps. Sinon, comme tu l'as dit, cela peut provoquer un changement de comportement du code, qui serait indétectable et donc galère à corriger.
    Dans ce cas là, pourquoi ne pas interdire l'ambiguïté au niveau du compilateur/norme ?

    Et dans le cas du vecteur, quel serait la "bonne solution" ?
    Ne pas pouvoir ajouter l'initializer_list après coup est aussi relativement dommage.

    Il faut probablement éviter d'utiliser les initializer_list constructor, excepté dans les rares cas de création d'une classe "conteneur" (type vector, list, etc). Dans ce cas, on peut considérer que l'utilisateur sait qu'il y a une différence entre () et {}, du fait que la STL utilise aussi cette approche.
    Le C++ a plutôt, je pense, une philosophie, "soyons idiot-proof". Ex. cast implicite des void * en C est interdit en C++.
    Partir du principe que l'utilisateur connaît la différence me semble être, à mon sens, une erreur.

    Pour l'utilisation de "uniform initialisation", cela vient du fait qu'en C++03, il n'est pas toujours possible d'utiliser = ou () pour initialiser une variable. Alors que {} sera toujours utilisable :
    Je vois.

    int x();On déclare une fonction, il faudrait utiliser
    int x;ce qui perd parfois des utilisateurs, en effet.

    Mais d'un autre côté, int x{};, c'est deux caractère de trop pour moi, développeur fainéant.


    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    int x[] = { 1, 2, 3}; // ok
    vector<int> x = { 1, 2, 3}; // ok en C++11, pas en C++03
    Donc là, c'est les initializer_list.

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    class A {
      int x(0); // erreur
      int x = 0; // ok
      int x{0}; // ok
    };
    C'est à mon sens le problème le plus gênant, en effet.
    Mais j'aurais plutôt préféré autoriser int x(0) que "d'interdire sans interdire" l'ambiguïté c(int), c(intializer_list).

    C'est d'ailleurs surtout cela qui me gêne.
    On dit "chiffrer" pas "crypter" !

    On dit "bibliothèque" pas "librairie" !

    Ma page DVP : http://neckara.developpez.com/

  17. #17
    Membre averti

    Profil pro
    Inscrit en
    décembre 2013
    Messages
    298
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : décembre 2013
    Messages : 298
    Points : 307
    Points
    307

    Par défaut

    Citation Envoyé par Neckara Voir le message
    Dans ce cas là, pourquoi ne pas interdire l'ambiguïté au niveau du compilateur/norme ?
    Et dans le cas du vecteur, quel serait la "bonne solution" ?
    Il faudrait voir les discussions qui ont menées a ce choix. Mais c'est clairement un choix qui a été fait volontairement (pas un effet indésirable non prévu) a priori.
    Les initializer_list constructor sont prioritaires sur les autres constructeurs, si tu écris :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    vector<double> v { static_cast<size_t>(1) };
    Il y aura une conversion int vers double puis appel du constructeur par liste, même si le constructeur vector(size_t) correspond mieux

    Citation Envoyé par Neckara Voir le message
    Ne pas pouvoir ajouter l'initializer_list après coup est aussi relativement dommage.
    Si tu n'as pas une sémantique de conteneur, la question ne se pose pas, cela n'a pas de sens d'ajouter ce constructeur.
    Si tu as une sémantique de conteneur, il faut effectivement faire le choix des le début. A mon sens, le plus simple est de respecter l'API de la STL et proposer ce constructeur (au pire, tu mets un static_assert(false, "don't do that!") dedans pour explicitement interdire son utilisation )

    Citation Envoyé par Neckara Voir le message
    Le C++ a plutôt, je pense, une philosophie, "soyons idiot-proof". Ex. cast implicite des void * en C est interdit en C++.
    Partir du principe que l'utilisateur connaît la différence me semble être, à mon sens, une erreur.
    Si c’était "idiot proof", il n'y aurait pas du tout de void*.

    Je ne voulais pas dire qu'il fallait partir du principe que l'utilisateur connait cette différence. Je voulais dire que ce problème existe, indépendamment de ce que tu feras. Le comité aurait probablement du voir ce problème plus en détail, mais pour le moment, il existe.
    Donc tu peux partir du principe que tu n'introduis pas de nouvelle difficultés en faisant cela, tu utilises une difficulté existante. Le seul moyen pour éviter cette difficulté est de ne pas utiliser les initializer_list...

    Citation Envoyé par Neckara Voir le message
    int x;ce qui perd parfois des utilisateurs, en effet.

    Mais d'un autre côté, int x{};, c'est deux caractère de trop pour moi, développeur fainéant.
    Attention, c'est pas la même chose.
    Dans le premier cas, tu as une default-initilization, dans le second tu as une value initialization.
    Pour un objet avec constructeur, tu vas appeler le constructeur par défaut dans les 2 cas.
    Pour un build-in type, tu vas avoir une variable qui aura une valeur aléatoire dans le premier cas et une "zero initialization" dans l'autre (selon le type : 0, false, nullptr, etc)

    HS : pour ajouter a la confusion (pour les débutants), selon la position des parenthèses, tu as une déclaration de fonction ou d'un valeur :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    int i(); // declaration d'une fonction
    int(); // creation d'un int
    Citation Envoyé par Neckara Voir le message
    Donc là, c'est les initializer_list.
    C'est le constructeur par liste pour vector et une aggregate initialization pour le tableau style C.

    Citation Envoyé par Neckara Voir le message
    Mais j'aurais plutôt préféré autoriser int x(0) que "d'interdire sans interdire" l'ambiguïté c(int), c(intializer_list).
    C'est d'ailleurs surtout cela qui me gêne.
    Tu n'es pas le seul
    Je crois qu'il y a des discussions sur ce point, il faudrait vérifier.
    Pour le moment, on doit continuer a expliquer les différentes syntaxes. Mais si on commence par {}, il y a quand même moins de cas particulier a expliquer. La situation est moins pire qu'avec le C++03 (bien qu'au final, un "vrai" développeur C++ devra connaitre les syntaxes C++11 et C++03)

  18. #18
    Membre expert

    Avatar de germinolegrand
    Homme Profil pro
    Développeur de jeux vidéo
    Inscrit en
    octobre 2010
    Messages
    738
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Puy de Dôme (Auvergne)

    Informations professionnelles :
    Activité : Développeur de jeux vidéo
    Secteur : Tourisme - Loisirs

    Informations forums :
    Inscription : octobre 2010
    Messages : 738
    Points : 3 754
    Points
    3 754

    Par défaut

    Un beau bazar ces {} vs ().

    auto x = {"qsdf", "323"}; c'est ça la plus belle des aberrations (que Meyers fustige si je ne me trompe ?).

    Et il va effectivement falloir apprendre la totalité des subtilités pour peu qu'on ait à toucher des libs qui ne soient pas en C++11.

  19. #19
    Membre averti

    Profil pro
    Inscrit en
    décembre 2013
    Messages
    298
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : décembre 2013
    Messages : 298
    Points : 307
    Points
    307

    Par défaut

    Citation Envoyé par germinolegrand Voir le message
    auto x = {"qsdf", "323"}; c'est ça la plus belle des aberrations (que Meyers fustige si je ne me trompe ?).
    D'un autre côté, tu aurais voulu quoi comme type pour auto ici ?

    Je crois que c'est surtout avec une valeur qui pose problème (du fait que l'on a des écritures très proches, mais qui ne donnent pas à chaque fois le même type déduit)
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    int i { 0 }; // int
    auto i = 0; // int
    auto i { 0 } // initialiser_list
    auto i = { 0 } // initialiser_list
    Je me souviens plus ce que Meyers dit là dessus

  20. #20
    Membre averti

    Profil pro
    Étudiant
    Inscrit en
    décembre 2004
    Messages
    497
    Détails du profil
    Informations personnelles :
    Âge : 31
    Localisation : France

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : décembre 2004
    Messages : 497
    Points : 444
    Points
    444

    Par défaut

    moi ça me saoule ce troll qui revient sans cesse que apprendre le C c'est pas intéressant, qu'on peut apprendre le C++ sans apprendre le C d'abord,

    c'est débile, et ça devrait être clair depuis le temps

    moi j'ai très bien vu la différence de compréhension entre quand je programmais à 12 ans en Basic puis quand à 19 ans je suis passé au C et que j'ai programmé des fonctions de manipulation de char* et de liste chaînée, et vous aussi vous l'avez vécu donc bon : stop, fini, merci

    et alors vos discussions sur "comment apprendre aux élèves le C++ version pointeur intelligents boost etc." mais c'est d'un ridicule : s'ils sont pas capables vos élèves d'apprendre eux-mêmes tout ça ben ça sert à rien d'essayer de le leur apprendre, c'est comme ça la programmation c'est mieux d'avoir 105 de QI sinon ça marche pas trop hein, alors vu les tonnes de langages d'api et tout ça, apprendre les spécificités d'un truc comme le C++11 alors qu'il y a beaucoup plus intéressant en bac+2 ou bac+3 : apprendre la cryptographie ou la programmation 3D ou même je sais pas comment marche mathematica (bon aucun prof n'est capable de l'enseigner mais ça peut changer), des trucs qui sont objectivement difficiles à apprendre tout seul et qui permettent de former l'esprit bien plus ..

Discussions similaires

  1. Sélectionner des dates courant sur plusieurs mois
    Par Christophe Charron dans le forum Requêtes
    Réponses: 1
    Dernier message: 11/01/2009, 14h03
  2. [JSTL] Item courant sur <c:forEach..>
    Par ginkas31 dans le forum Taglibs
    Réponses: 3
    Dernier message: 19/02/2008, 19h11
  3. Marquer le noeuds courant sur une treeView
    Par Lynecoln dans le forum VB 6 et antérieur
    Réponses: 3
    Dernier message: 10/11/2006, 09h11
  4. [Derby] Requete date courante sur un champ Timestamp
    Par spekal dans le forum Langage SQL
    Réponses: 2
    Dernier message: 15/09/2006, 10h54
  5. courant sur port extern
    Par bobymaw dans le forum C++Builder
    Réponses: 16
    Dernier message: 06/05/2004, 13h16

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