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 :

CppCon 2016 : Bjarne Stroustrup parle de l'évolution de C++


Sujet :

C++

  1. #1
    Chroniqueur Actualités

    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    mars 2013
    Messages
    6 372
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Canada

    Informations professionnelles :
    Activité : Administrateur de base de données

    Informations forums :
    Inscription : mars 2013
    Messages : 6 372
    Points : 154 899
    Points
    154 899
    Par défaut CppCon 2016 : Bjarne Stroustrup parle de l'évolution de C++
    CppCon 2016 : Bjarne Stroustrup parle de l'évolution de C++ et s'intéresse à son passé,
    à son présent mais aussi à son futur

    Durant l’édition 2016 de la conférence annuelle de la communauté C++ CppCon, le professeur de science informatique danois et créateur du langage Bjarne Stroustrup a tenu à présenter les évolutions du langage, notamment en évoquant son passé, son présent, mais également son futur.

    « Je me demandais ce dont j’allais parler durant cette conférence en tant qu’orateur. Puis j’ai regardé le programme et j’ai réalisé qu’il y avait une grosse liste de choses bien détaillées, que ce soit sur le langage, les bibliothèques, etc. Aussi, je me suis dit que je n’allais pas me lancer dans cette voie. J’essaie au contraire de parler de quelque chose de plus général. J’essaie de parler d’évolution. J’essaie de retourner en arrière pour comprendre la raison pour laquelle C++ a connu du succès », a-t-il déclaré en guise d’introduction devant l’auditoire.

    Les points sur lesquels Bjarne Stroustrup s'est appesanti sont notamment :
    • le passé : pourquoi est-ce que C++ a connu le succès ?
      • en répondant aux questions avant que les gens ne les posent,
      • en ne suivant pas la masse ;
    • le présent : comment la standardisation façonne-t-elle le C++ ?
      Elle aspire à la stabilité via la compatibilité ;
    • le futur : que devons-nous faire ?
      • concentrer nos efforts à servir la communauté C++ actuelle et à venir,
      • ne pas se dissiper en essayant de plaire à tous ;
    • le futur proche : comment s'y préparer ?
      • trouver des moyens pour utiliser des fonctionnalités des spécifications techniques ISO,
      • développer des lignes directrices.

    Durant son intervention, il a donné son avis, par exemple, sur les fonctionnalités d’un bon langage de programmation. Selon lui, bien que tout langage ait besoin de bonnes fonctionnalités fondamentales (par exemple, des mécanismes pour aider à concevoir son code, mais également une bibliothèque standard), un (bon) langage ne saurait se limiter à être un ensemble de bonnes fonctionnalités.

    Il s’est également attardé sur les décisions majeures qui ont été prises dans la conception du langage et a indiqué sur une ligne du temps leur impact sur la façon de programmer des développeurs.


    Il a expliqué que, pour sa part, les fonctionnalités majeures sont celles qui changent la façon dont les gens pensent le code, tout comme les concepts, qui devraient arriver dans la prochaine version de C++. Il a néanmoins indiqué qu’une combinaison de fonctionnalités mineures peut avoir un impact majeur.

    À la question de savoir ce qui fait une bonne extension, il explique que les réponses sont très variées. Du point de vue des développeurs, une bonne extension « aide les gens comme moi et mon projet » :
    • elle résout des problèmes spécifiques ;
    • elle ne nécessite pas de lecture fastidieuses de mode d’emploi ;
    • elle isole le changement ;
    • elle n’entraîne pas de plantage.

    Les difficultés rencontrés par les développeurs lors de la conception d’une extension sont :
    • un manque d’expérience dans la planification à long terme ;
    • des objectifs très souvent définis par d’autres personnes ;
    • une évaluation des conséquences sur le court terme.

    Du point de vue des concepteurs, une bonne extension « va aider de façon significative la communauté des utilisateurs pendant la prochaine décennie » :
    • elle répond à un problème général / fondamental ;
    • elle fait que le langage est utilisé de façon plus régulière et facilement ;
    • elle améliore la réputation de C++.

    Malgré tout, il a reconnu que toutes les extensions font plus ou moins de mal :
    • elles rendent obsolètes certains supports d’apprentissages ;
    • elles peuvent avoir un faible ratio bénéfice / coût ;
    • elles pourraient ne venir en aide qu’à une portion de la communauté ;
    • elles pourraient induire des coûts à des personnes qui ne les utilisent pas ;
    • elles pourraient être une entrave pour les efforts de pratique de programmation.


    Tous ces critères ont aidé à façonner C++17. Ainsi, des modifications dont les effets sont relativement isolés ont été acceptées sans problème, comme de simples variables globales, c'est-à-dire la syntaxe inline int x = f();. Au contraire, la convention d'appel unifiée a été rejetée : elle proposait que l'écriture f(x) soit équivalente à x.f() dans tous les cas.

    Dans son intervention, il évoque de nombreux points intéressants relatifs à l'évolution de C++.


    Source : YouTube

    Voir aussi :

    CppCon : Bjarne Stroustrup annonce le projet C++ Core Guidelines, pour aider les développeurs à utiliser le C++ moderne de façon plus efficace
    Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités

  2. #2
    Membre expérimenté
    Profil pro
    Inscrit en
    février 2004
    Messages
    1 816
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : février 2004
    Messages : 1 816
    Points : 1 544
    Points
    1 544
    Par défaut
    Il y a des moments, ça me fou un peu la trouille ces évolutions, mais c'est normal, c'est du changement.

    Je fais du c++ depuis 12 ans, appliqué à 6 domaines différents, de la 3D temps réelle aux problèmes combinatoires en passant par l'embarqué, autant dire que pour moi, dès que quelque chose change, ça me fait peur.

    Un truc qui m'horripile du C++11 c'est le concept d'"auto" avec pour objectif de pouvoir facilement changer le type des choses sans devoir repasser partout dans le code. Mais du coup, à manipuler ce code, on ne sait plus ce que l'on manipule. J'ai pas bien envie que C++ devienne JS ou PHP, ça le dénaturerait.

    En revanche le concept du "vol de mémoire" est parfait. Ça c'était un vrai besoin, en terme de performance mais pas que, d'utilisabilité et de lisibilité aussi, même si aujourd'hui je ne l'utilise pas (les réflexes font que).

    Pour moi si ça doit évoluer, c'est sur la standardisation de fonctionnalités plus haut niveau indépendantes de bibliothèques spécifiques au système visé. Par exemple ce qu'ils ont fait avec les threads ou les signaux. Avant on utilisait soit des outils externes tels que boost::thread ou pthread, ou alors on utilisait les "API" système, donc non portables et donc on devait jongler entre les bibliothèques en fonction du système visé, et les IDE aussi.

    Désormais "#include <thread>" ça suffit et ça fonctionne partout, sans créer X pipelines dans go-cd selon X systèmes visés à gérer, 2 environnements de développement à créer, maintenir etc.

    Du coup, la syntaxe.. bof bof comme type d'évolution
    "Heureusement qu'il y avait mon nez, sinon je l'aurais pris en pleine gueule" Walter Spanghero

  3. #3
    Modérateur
    Avatar de Gugelhupf
    Homme Profil pro
    Analyste Programmeur
    Inscrit en
    décembre 2011
    Messages
    1 309
    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 309
    Points : 3 639
    Points
    3 639
    Billets dans le blog
    12
    Par défaut
    Citation Envoyé par mister3957
    Un truc qui m'horripile du C++11 c'est le concept d'"auto" avec pour objectif de pouvoir facilement changer le type des choses sans devoir repasser partout dans le code. Mais du coup, à manipuler ce code, on ne sait plus ce que l'on manipule. J'ai pas bien envie que C++ devienne JS ou PHP, ça le dénaturerait.
    En JS, PHP, Python, le typage est implicite, tu peux ne pas savoir ce que tu manipules si l'initialisation/affectation se fait hors scope, mais en C++ avec auto ou en C# avec var (qui n'a rien avoir avec celui du JS) c'est juste du sucre syntaxique, tu appliques l'inférence de type, ton IDE peut facilement t'aider à retrouver ton type si tu pointes ton curseur sur le nom de ta variable, tu sais ce que tu manipules. La preuve que l'inférence de type est différent des langages de script : elle ne s'applique pas aux paramètres de fonction
    N'hésitez pas à consulter la FAQ Java, lire les cours et tutoriels Java, et à poser vos questions sur les forums d'entraide Java

    Ma page Developpez | Mon profil Linkedin | Vous souhaitez me contacter ? Contacter Gokan EKINCI

  4. #4
    Membre averti

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

    Informations forums :
    Inscription : décembre 2013
    Messages : 323
    Points : 429
    Points
    429
    Par défaut
    JS et PHP ont un système de typage souvent décrié, donc si on se base sur ces exemples, cela laisse l'impression que l'inférence de type, c'est mal. Mais si on regarde des langages plus récents, comme D, Go, Rust, etc. ils utilisent l'inférence de type par défaut.

    Citation Envoyé par Gugelhupf Voir le message
    tu sais ce que tu manipules. La preuve que l'inférence de type est différent des langages de script : elle ne s'applique pas aux paramètres de fonction
    Pas sur que ce soit une bonne preuve...

    - les fonctions lambdas autorisent l'inférence de type des les parametres.

    - c'est en discussion pour que les fonctions puissent faire cela dans le futur (dans Concept je crois. C'est déjà implémenté dans GCC)

    - et de toute facon, cela existe deja !
    Il ne faut pas oublier que quand on écrit des fonctions template, cela passe par de l'inférence de type.

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    template<typename T>
    void f(T x);
     
    f(123); // inference
    Quand on n'a pas besoin de "T" dans la fonction, auto fera exactement la même chose.

    Et l'argument "on ne sait plus ce que l'on manipule" s'applique aussi aux templates. Cela veut dire qu'il faut aussi les rejeter ?

  5. #5
    Expert confirmé
    Avatar de Pyramidev
    Homme Profil pro
    Développeur
    Inscrit en
    avril 2016
    Messages
    1 215
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Développeur

    Informations forums :
    Inscription : avril 2016
    Messages : 1 215
    Points : 5 157
    Points
    5 157
    Par défaut
    Citation Envoyé par mister3957 Voir le message
    Un truc qui m'horripile du C++11 c'est le concept d'"auto" avec pour objectif de pouvoir facilement changer le type des choses sans devoir repasser partout dans le code. Mais du coup, à manipuler ce code, on ne sait plus ce que l'on manipule. J'ai pas bien envie que C++ devienne JS ou PHP, ça le dénaturerait.
    auto a plusieurs buts. Personnellement, au quotidien, les moments où j'ai le plus envie d'utiliser auto, c'est quand j'appelle une fonction de la STL dont le type de retour est connu, mais fait 3 km.

    Exemple :
    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
    // Sans auto :
    {
        std::pair<std::map<IdUtilisateur, Utilisateur>::iterator, bool> tmp = mapUtilisateurs.insert(std::make_pair(id, utilisateur));
        bool identifiantPasDejaUtilise = tmp.second;
        // ...
    }
     
    // Avec auto :
    {
        auto tmp = mapUtilisateurs.insert(std::make_pair(id, utilisateur));
        bool identifiantPasDejaUtilise = tmp.second;
        // ...
    }
     
    // Avec les structured bindings de C++17 :
    {
        auto [it, identifiantPasDejaUtilise] = mapUtilisateurs.insert(std::pair(id, utilisateur));
        // ...
    }

  6. #6
    Membre confirmé
    Profil pro
    Développeur informatique
    Inscrit en
    mai 2012
    Messages
    163
    Détails du profil
    Informations personnelles :
    Localisation : France, Côtes d'Armor (Bretagne)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : mai 2012
    Messages : 163
    Points : 624
    Points
    624
    Par défaut
    Il n'y a pas vraiment d'inférence de type en C++. Le mot-clé "auto" permet uniquement de déduire le type, à partir de l'initialisation. D'ailleurs les docs classiques parlent bien de déduction (https://isocpp.org/wiki/faq/cpp11-language#auto, http://en.cppreference.com/w/cpp/language/auto) et la page wikipedia sur "l'inférence de type" fait beaucoup discuter (https://en.wikipedia.org/wiki/Talk:Type_inference).

    L'inférence de type détermine l'ensemble des types possibles d'après le contexte d'utilisation complet de la variable. Cela correspond aux types polymorphes de ocaml/haskell (et ça fonctionne aussi pour les paramètres de fonction).

    Dans le contexte du typage dynamique des langages de script, il s'agit plutôt du duck-typing.

  7. #7
    Expert éminent
    Homme Profil pro
    Analyste/ Programmeur
    Inscrit en
    juillet 2013
    Messages
    4 067
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Analyste/ Programmeur

    Informations forums :
    Inscription : juillet 2013
    Messages : 4 067
    Points : 9 122
    Points
    9 122
    Par défaut
    Citation Envoyé par zobal Voir le message
    il s'agit plutôt du duck-typing.
    Je ne pense pas que ce soit pareil

    Si je ne dis pas de bêtises, c'est la compilation qui va remplacer le mot clef auto par le vrai type.
    Alors que le duck-typing (comme celui de l'Objective C) c'est à l'exécution.


    Citation Envoyé par mintho carmo Voir le message
    Et l'argument "on ne sait plus ce que l'on manipule" s'applique aussi aux templates. Cela veut dire qu'il faut aussi les rejeter ?
    Mais avec les templates , tu as une notion de contrat.

  8. #8
    Membre expert
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    juin 2011
    Messages
    706
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Hérault (Languedoc Roussillon)

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

    Informations forums :
    Inscription : juin 2011
    Messages : 706
    Points : 3 424
    Points
    3 424
    Par défaut
    Citation Envoyé par foetus Voir le message
    Je ne pense pas que ce soit pareil
    C'est exactement ce qu'il dit: c'est différent.
    Je pense que le reproche mister3957 vient dans la relecture d'un code qui n'utilise que auto: on perd l'information de type à la lecture. Personnellement, je trouve cette information peu utile puisqu'il reste le nom de la variable, la valeur d'initialisation et le contexte d'utilisation.

    Citation Envoyé par foetus Voir le message
    Mais avec les templates , tu as une notion de contrat.
    Pas plus qu'avec auto. Il y a certes une information en plus qui est le nom du type, mais cela reste un contrat implicite qui se vérifie au moment où de l'utilisation. Pas d'opérateur + ? Erreur sur la ligne qui l'utilise. Une notion de contrat devrait être vérifiée au moment de l'initialisation, comme ce que proposent les concepts.

    Si j'ai bien compris les quelques trucs vu sur les concepts, ceux-ci pourront remplacer une bonne partie des types templates et auto, tout en offrant une vérification d'interface implicite via un contrat nommé.
    Il y aussi une généralisation de auto jusqu'au paramètre de template pour les paramètres qui n'ont pas de contrat défini.

  9. #9
    Membre expérimenté
    Profil pro
    Inscrit en
    février 2004
    Messages
    1 816
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : février 2004
    Messages : 1 816
    Points : 1 544
    Points
    1 544
    Par défaut
    Citation Envoyé par Pyramidev Voir le message
    auto a plusieurs buts. Personnellement, au quotidien, les moments où j'ai le plus envie d'utiliser auto, c'est quand j'appelle une fonction de la STL dont le type de retour est connu, mais fait 3 km.

    Exemple :
    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
    // Sans auto :
    {
        std::pair<std::map<IdUtilisateur, Utilisateur>::iterator, bool> tmp = mapUtilisateurs.insert(std::make_pair(id, utilisateur));
        bool identifiantPasDejaUtilise = tmp.second;
        // ...
    }
     
    // Avec auto :
    {
        auto tmp = mapUtilisateurs.insert(std::make_pair(id, utilisateur));
        bool identifiantPasDejaUtilise = tmp.second;
        // ...
    }
     
    // Avec les structured bindings de C++17 :
    {
        auto [it, identifiantPasDejaUtilise] = mapUtilisateurs.insert(std::pair(id, utilisateur));
        // ...
    }
    C'est bien pratique en effet, mais dans ce cas, tu sais ce qu'est tmp avant d'appeler tmp.second.

    Il se passe quoi quand tu ne le sais pas ? Car "auto" que je traduirais par "truc", "machin" ou "bidule"..
    "Heureusement qu'il y avait mon nez, sinon je l'aurais pris en pleine gueule" Walter Spanghero

  10. #10
    Membre chevronné Avatar de Ehonn
    Homme Profil pro
    Étudiant
    Inscrit en
    février 2012
    Messages
    788
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 31
    Localisation : France

    Informations professionnelles :
    Activité : Étudiant
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : février 2012
    Messages : 788
    Points : 2 160
    Points
    2 160
    Par défaut
    Citation Envoyé par mister3957 Voir le message
    Il se passe quoi quand tu ne le sais pas ?
    Il faut regarder la documentation (le type est déterminé automatiquement et statiquement par le compilateur).

  11. #11
    Membre expérimenté
    Profil pro
    Inscrit en
    février 2004
    Messages
    1 816
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : février 2004
    Messages : 1 816
    Points : 1 544
    Points
    1 544
    Par défaut
    Citation Envoyé par Ehonn Voir le message
    Il faut regarder la documentation (le type est déterminé automatiquement et statiquement par le compilateur).
    Donc ça apporte de la "magie" qui nécessite obligatoirement de la lecture de docs (et donc du temps) pour la comprendre afin pouvoir la manipuler, juste pour savoir ce que l'on manipule.

    Ça pue la régression cette histoire
    "Heureusement qu'il y avait mon nez, sinon je l'aurais pris en pleine gueule" Walter Spanghero

  12. #12
    Membre chevronné Avatar de Ehonn
    Homme Profil pro
    Étudiant
    Inscrit en
    février 2012
    Messages
    788
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 31
    Localisation : France

    Informations professionnelles :
    Activité : Étudiant
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : février 2012
    Messages : 788
    Points : 2 160
    Points
    2 160
    Par défaut
    Citation Envoyé par mister3957 Voir le message
    Donc ça apporte de la "magie" qui nécessite obligatoirement de la lecture de docs (et donc du temps) pour la comprendre afin pouvoir de la manipuler, juste pour savoir ce que l'on manipule.
    La première fois que tu vois un nouveau type, il faut aller voir la documentation pour savoir comment l'utiliser / le manipuler (auto ou pas).
    Maintenant, il faut soit aller voir la documentation, soit demander à son compilateur, pour connaître le type.

    Citation Envoyé par mister3957 Voir le message
    Ça pue la régression cette histoire
    Non, car on "utilisait" déjà auto avant (sous une autre forme) :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    std::vector<iterator>::reverse_iterator it = v.rbegin();
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    std::vector<bool>::size_type const n = v.size();
    Probablement le meilleur exemple :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    typedef boost::result_of<functor(int)>::type r = functor(7);
    auto est très justifié pour les les cas où, au final, le type de retour n'est pas important (contrairement aux services) (le nom de la fonction et/ou de la variable suffit).
    Dans l'exemple de Pyramidev, un std::pair est utilisé mais l'utilisation d'un std::tuple, d'un boost::optional ou de n'importe qu'elle classe qui offrent les même services (ou équivalents) est légitime.

  13. #13
    Membre confirmé
    Profil pro
    Développeur informatique
    Inscrit en
    mai 2012
    Messages
    163
    Détails du profil
    Informations personnelles :
    Localisation : France, Côtes d'Armor (Bretagne)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : mai 2012
    Messages : 163
    Points : 624
    Points
    624
    Par défaut
    Citation Envoyé par mister3957 Voir le message
    Donc ça apporte de la "magie" qui nécessite obligatoirement de la lecture de docs (et donc du temps) pour la comprendre afin pouvoir la manipuler, juste pour savoir ce que l'on manipule.

    Ça pue la régression cette histoire
    Si c'est une blague, ça commence à être lourd.
    Sinon, comme dit précédemment, le type est celui de la valeur d'initialisation.

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    int a = 4;
    auto x = a;           // x est de type int
     
    float b = 3;
    auto y = b;           // y est de type float
     
    vector<string> v {"texte1", "texte2"};
    auto tab = v;             // tab est de type vector<string>
    auto str = v.front();     // str est de type string
    auto iter = v.begin();    // iter est de type vector<string>::iterator
     
    auto f = [] (int n) { return n > 0; };  // f est de type function<bool(int)>
    Oulala que c'est magique.

  14. #14
    Membre expérimenté
    Profil pro
    Inscrit en
    février 2004
    Messages
    1 816
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : février 2004
    Messages : 1 816
    Points : 1 544
    Points
    1 544
    Par défaut
    Bon moi je ne m'y fait pas, c'est surement trop "magique" pour moi, surtout quand ce que l'on fait est destiné à être partagé, utilisé ailleurs.

    La résistance au changement, sûrement..
    "Heureusement qu'il y avait mon nez, sinon je l'aurais pris en pleine gueule" Walter Spanghero

  15. #15
    Membre chevronné Avatar de Ehonn
    Homme Profil pro
    Étudiant
    Inscrit en
    février 2012
    Messages
    788
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 31
    Localisation : France

    Informations professionnelles :
    Activité : Étudiant
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : février 2012
    Messages : 788
    Points : 2 160
    Points
    2 160
    Par défaut
    Je n'ai rien contre toi (je préfère le préciser ) mais j'ai une question sur un point spécifique :

    À quel moment typedef boost::result_of<functor(int)>::type n'est pas aussi "magique" qu'auto ?

    PS : @zobal
    Note que vector<string>::iterator n'est pas un type vraiment/entièrement définit par la norme, on sait juste que ça respecte le "concept" de random access iterator (?)
    Idem, pour les lambdas, le type de retour n'est pas définit (mais convertissible vers std::function).

  16. #16
    Membre expérimenté
    Profil pro
    Inscrit en
    février 2004
    Messages
    1 816
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : février 2004
    Messages : 1 816
    Points : 1 544
    Points
    1 544
    Par défaut
    Citation Envoyé par zobal Voir le message
    Si c'est une blague, ça commence à être lourd.
    Sinon, comme dit précédemment, le type est celui de la valeur d'initialisation.

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    int a = 4;
    auto x = a;           // x est de type int
     
    float b = 3;
    auto y = b;           // y est de type float
     
    vector<string> v {"texte1", "texte2"};
    auto tab = v;             // tab est de type vector<string>
    auto str = v.front();     // str est de type string
    auto iter = v.begin();    // iter est de type vector<string>::iterator
     
    auto f = [] (int n) { return n > 0; };  // f est de type function<bool(int)>
    Oulala que c'est magique.
    Parce que là c'est un simple petit programme de test.

    Quand ça parle de plusieurs centaines de milliers de lignes de code, fait en équipe, via des bibliothèques partagées (statiques ou dynamiques) entre plusieurs centres de services, qu'est-ce que tu en sais que v.front() est de type "std::string" puisqu'il est de type "auto" ?

    Si à l'autre bout du monde on change le type car auto le promet que ça se fera sans encombre, qu'est-ce qui te garantie que le .c_str() fonctionnera ?

    Ton "auto str" peut-il varier de std::string à const char* aussi simplement sans impact, par magie ?

    Perso je préfère avoir le type sous les yeux, à commencer par le préfixe de mes variables et de celles que j'expose en paramètre, et le "const compliant", quitte à les changer quant le type change. Certes ça demande du taf de singe, mais au moins on sait ce que l'on manipule sur le moment et pas besoin de remonter à la source (qui peut être très lointaine dans le code) afin de deviner pour déduire les choses, d'en présupposer d'autres ou de se reposer sur les erreurs / warnings du compilateur pour me laisser guider.

    "auto str", c'est bien joli mais qu'est-ce que je peux en faire de ce "str" si je ne sais pas ce que sais ?
    "Heureusement qu'il y avait mon nez, sinon je l'aurais pris en pleine gueule" Walter Spanghero

  17. #17
    Rédacteur/Modérateur
    Avatar de JolyLoic
    Homme Profil pro
    Développeur informatique
    Inscrit en
    août 2004
    Messages
    5 460
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 47
    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 460
    Points : 16 193
    Points
    16 193
    Par défaut
    As tu déjà essayé auto sur des vrais projets ? Moi, oui, et je n'ai pas rencontré les problèmes dont tu parles.
    Au contraire, je trouve le code plus lisible avec auto que sans. Parce qu'il permet de s'éloigner du type d'une variable, pour se concentrer sur son rôle. Et que c'est ça qui compte le plus.

    Citation Envoyé par mister3957 Voir le message
    Quand ça parle de plusieurs centaines de milliers de lignes de code, fait en équipe, via des bibliothèques partagées (statiques ou dynamiques) entre plusieurs centres de services, qu'est-ce que tu en sais que v.front() est de type "std::string" puisqu'il est de type "auto" ?
    Je n'en sais rien, et je m'en moque. Ce qui compte c'est de savoir que v contient des chaînes, et quelles chaînes (est-ce que ce sont des noms, des titres, des phrases...). Savoir si ce sont des std::string, des QString, des glib::ustring... n'importe pas vraiment. C'est similaire du fameux "program to interface, not implementation" des langages comme C# ou Java.

    Citation Envoyé par mister3957 Voir le message
    Si à l'autre bout du monde on change le type car auto le promet que ça se fera sans encombre, qu'est-ce qui te garantie que le .c_str() fonctionnera ?
    Personne (et auto n'a jamais promis qu'on pouvait changer de type de manière 100% transparente...). Dans certains cas ça marchera, dans d'autres cas, il faudra apporter des modifications fastidieuses au code suite au refactoring. En pratique, il y a quand même pas mal de cas où ça marche, les templates ont bien formé les gens à utiliser des interfaces identiques. Mais sans auto, c'est garanti que ça ne marcherait jamais, voire pire, que ça marcherait en ajoutant silencieusement des opérations inutiles (conversion d'une chaîne en une autre, par exemple).

    Citation Envoyé par mister3957 Voir le message
    Perso je préfère avoir le type sous les yeux, à commencer par le préfixe de mes variables et de celles que j'expose en paramètre, et le "const compliant", quitte à les changer quant le type change. Certes ça demande du taf de singe, mais au moins on sait ce que l'on manipule sur le moment et pas besoin de remonter à la source (qui peut être très lointaine dans le code) afin de deviner pour déduire les choses, d'en présupposer d'autres ou de se reposer sur les erreurs / warnings du compilateur pour me laisser guider.
    Si la source des variables est loin dans le code, il y a un autre problème. J'ai très rarement plus de 20 lignes entre le moment où une variable est initialisée, et le moment où elle est utilisée pour la dernière fois (c'est souvent moins de 10). Et voir comment la variable est initialisée est suffisant pour savoir quoi en faire, quand les noms de variables/fonctions sont bien choisis. Et s'ils ne sont pas bien choisis, ce n'est pas de connaître le type qui va aider.

    Citation Envoyé par mister3957 Voir le message
    "auto str", c'est bien joli mais qu'est-ce que je peux en faire de ce "str" si je ne sais pas ce que sais ?
    auto str, tu ne peux rien en faire, et le compilateur non plus, on est bien d'accord. auto str = f();, je suis aussi d'accord qu'on ne peut pas en faire grand-chose non plus. Mais franchement, std::string str = f();, je saurais lui faire faire des choses, certes, mais des choses utiles ? Non. Savoir que str est une chaîne ne m'aide absolument pas à savoir ce qu'elle contient et ce qu'il faudrait que j'en fasse. auto searchCriterion = mySearchDialog.getResult();, là, oui, je commence à bien savoir qu'en faire. Et la plupart du temps, je n'ai pas besoin du tout de savoir le type exact pour manipuler mon seachCriterion. Je peux le placer dans une searchHistory, le transmettre à un searchEngine et demander à ce dernier des searchResults... Et je suis certain que tu as compris en quoi consistaient les opérations dont je parlais, alors même que je n'ai pas précisé si searchCriterion était un std::string, un QString, une std::regex, une classe (avec une string, un bool caseSensitive, et une enum normal/regex/wildcards)...

    J'aurais pu écrire ce code : SearchCriterion searchCriterion = mySearchDialog.getResult();, là, il n'y a plus d'auto, mais je ne trouve pas que le code gagne en lisibilité. J'aurais aussi pu l'écrire (en supposant que je me lie au fait qu'actuellement, un searchCriterion est juste une chaîne, et que je devrais revenir là-dessus si je désire enrichir mes possibilités de recherche : std::string searchCriterion = mySearchDialog.getResult();. Est-ce pour autant que j'ai vraiment appris plus de choses sur searchCriterion ?
    On pourrait me dire, "oui, tu sais que c'est une std::string, donc par exemple, tu sais que tu as le droit d'écrire if(!searchCriterion.empty()) searchCriterion[0] = 'a';". Sauf qu'en fait, c'est faux. On n'a pas le droit d'écrire ça, car c'est une chaîne de recherche, et dans mon cas, une recherche peut avoir une syntaxe spéciale, validée par mySearchDialog.getResult();, et que modifier un caractère comme ça à la hussarde peut rompre les invariants de mon code. Les invariants ne sont pas tous dans le système de type, mais aussi dans le contrat des fonctions. Ils sont sémantiques, pas syntaxiques. Ils sont donnés par les diverses fonctions qu'on appelle, celles-là même qui sont le point d'attention majeur quand on utilise auto. Et qu'utiliser auto permet justement de se focaliser sur la sémantique, en réduisant le bruit lié à la syntaxe.
    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
    Je donne des formations au C++ en entreprise, n'hésitez pas à me contacter.

  18. #18
    Expert éminent
    Homme Profil pro
    Analyste/ Programmeur
    Inscrit en
    juillet 2013
    Messages
    4 067
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Analyste/ Programmeur

    Informations forums :
    Inscription : juillet 2013
    Messages : 4 067
    Points : 9 122
    Points
    9 122
    Par défaut
    Citation Envoyé par JolyLoic Voir le message
    Je peux le placer dans une searchHistory, le transmettre à un searchEngine et demander à ce dernier des searchResults...
    Donc en gros pour simplifier , tu ne vas plus manipuler tes objets de façon directe (avec des getter/ setter, ... via les attributs) mais tu vas les transmettre à d'autres objets qui eux vont savoir quoi en faire (et les manipuler).

    Et donc le auto a du sens : je m'en fiche du type parce que je vais juste passer "la patate chaude" à un autre objet.

  19. #19
    Expert confirmé
    Avatar de Pyramidev
    Homme Profil pro
    Développeur
    Inscrit en
    avril 2016
    Messages
    1 215
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Développeur

    Informations forums :
    Inscription : avril 2016
    Messages : 1 215
    Points : 5 157
    Points
    5 157
    Par défaut
    Citation Envoyé par JolyLoic Voir le message
    std::string searchCriterion = mySearchDialog.getResult();. Est-ce pour autant que j'ai vraiment appris plus de choses sur searchCriterion ?
    On pourrait me dire, "oui, tu sais que c'est une std::string, donc par exemple, tu sais que tu as le droit d'écrire if(!searchCriterion.empty()) searchCriterion[0] = 'a';". Sauf qu'en fait, c'est faux. On n'a pas le droit d'écrire ça, car c'est une chaîne de recherche, et dans mon cas, une recherche peut avoir une syntaxe spéciale, validée par mySearchDialog.getResult();, et que modifier un caractère comme ça à la hussarde peut rompre les invariants de mon code. Les invariants ne sont pas tous dans le système de type, mais aussi dans le contrat des fonctions.
    S'il y a des invariants à respecter, je pense qu'il est préférable de créer une classe à part, même si elle est minimaliste :
    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
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    // SearchCriterion.h :
     
    #ifndef INCLUDE__BLABLABLA__SEARCH_CRITERION__H
    #define INCLUDE__BLABLABLA__SEARCH_CRITERION__H
     
    #include <string>
     
    namespace monprojet {
     
    /*!
     * \details   Les délais sont assez serrés, donc je n'ai pas encore eu le temps de
     *            faire une encapsulation complète de std::string.
     * \invariant Lisez le code de "SearchEngine.h".
     */
    class SearchCriterion
    {
    private:
        std::string m_string;
    public:
        explicit SearchCriterion(const std::string& searchCriterionString) :
            m_string(searchCriterionString)
        {
            // \todo : constructeur de SearchCriterion : lever exception si invariant non respecté
        }
        inline std::string toStdString() const
        {
            return m_string;
        }
    };
     
    } // namespace monprojet
     
    #endif
    Citation Envoyé par JolyLoic Voir le message
    J'aurais pu écrire ce code : SearchCriterion searchCriterion = mySearchDialog.getResult();, là, il n'y a plus d'auto, mais je ne trouve pas que le code gagne en lisibilité.
    Quand je lis SearchCriterion searchCriterion = mySearchDialog.getResult();, si je veux en savoir plus sur SearchCriterion, je vais lire "SearchCriterion.h". Donc, oui, je pense que le code gagne en lisibilité.

  20. #20
    Rédacteur/Modérateur
    Avatar de JolyLoic
    Homme Profil pro
    Développeur informatique
    Inscrit en
    août 2004
    Messages
    5 460
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 47
    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 460
    Points : 16 193
    Points
    16 193
    Par défaut
    Citation Envoyé par Pyramidev Voir le message
    S'il y a des invariants à respecter, je pense qu'il est préférable de créer une classe à part, même si elle est minimaliste
    Tu fais donc une classe pour les doubles positifs quand tu veux appeler sqrt, une autre pour les doubles strictements positifs quand tu veux appeler log, une autre pour les chaînes de caractères non vides, une autre pour...
    J'ai essayé à un moment sur du vrai code, mais j'ai trouvé ça bien trop lourd et finalement peu utile dès que tu es lié à des bibliothèques externes qui elles n'ont pas été écrites avec tes invariants en tête. Peut-être que si je devais coder dans un domaine où des vies humaines dépendent de mon code, je regarderai à nouveau ça de plus près, même si dans ces domaines, c'est encore la preuve de code (qui n'utilise pas le typage, mais des informations sémantiques) qui semble le plus utilisé...

    Citation Envoyé par Pyramidev Voir le message
    Quand je lis SearchCriterion searchCriterion = mySearchDialog.getResult();, si je veux en savoir plus sur SearchCriterion, je vais lire "SearchCriterion.h". Donc, oui, je pense que le code gagne en lisibilité.
    À partir du moment où tu parles de naviguer dans le code, on ne parle plus de la lisibilité passive, mais d'une lisibilité active. Avec mon IDE, que j'utilise auto ou pas, aller à la définition d'un type, c'est 1 touche à appuyer. Je pense que c'est plus efficace que toute stratégie qui serait basée sur une homonymie espérée entre nom de type et nom de fichier... Je ne suis donc pas très convaincu par cet argument...
    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
    Je donne des formations au C++ en entreprise, n'hésitez pas à me contacter.

Discussions similaires

  1. Itération suivant Bjarne Stroustrup ..Operand ?
    Par Go'Gaule dans le forum Débuter
    Réponses: 2
    Dernier message: 14/01/2012, 10h54
  2. Itération suivant Bjarne Stroustrup .
    Par Go'Gaule dans le forum Débuter
    Réponses: 6
    Dernier message: 12/01/2012, 16h37
  3. Principes et pratique avec c++ de Bjarne Stroustrup
    Par Go'Gaule dans le forum Débuter
    Réponses: 1
    Dernier message: 06/01/2012, 14h12
  4. P.P.P. de Bjarne Stroustrup C++
    Par Go'Gaule dans le forum Débuter
    Réponses: 16
    Dernier message: 05/12/2011, 22h15
  5. Réponses: 7
    Dernier message: 15/03/2007, 21h20

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