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.

http://www.developpez.com/public/ima...jeures-cpp.png

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

https://www.youtube.com/watch?v=_wzc...ature=youtu.be

Source : YouTube

Voir aussi :

:fleche: CppCon : Bjarne Stroustrup annonce le projet C++ Core Guidelines, pour aider les développeurs à utiliser le C++ moderne de façon plus efficace

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

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

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

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:

---

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 ?

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.

---

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:

---

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)); // ... }

---

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.

Citation:

---

Envoyé par zobal

il s'agit plutôt du duck-typing.

---

Je ne pense pas que ce soit pareil :mrgreen:

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

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 :mrgreen:, tu as une notion de contrat.

Citation:

---

Envoyé par foetus

Je ne pense pas que ce soit pareil :mrgreen:

---

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

Mais avec les templates :mrgreen:, 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.

Citation:

---

Envoyé par Pyramidev

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:

---

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

Citation:

---

Envoyé par mister3957

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

Citation:

---

Envoyé par Ehonn

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

Citation:

---

Envoyé par mister3957

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

Ça pue la régression cette histoire

---

Non, car on "utilisait" déjà auto avant (sous une autre forme) :

Code:

---

std::vector<iterator>::reverse_iterator it = v.rbegin();

---

Code:

---

std::vector<bool>::size_type const n = v.size();

---

Probablement le meilleur exemple :

Code:

---

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.

Citation:

---

Envoyé par mister3957

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:

---

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.

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

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

Citation:

---

Envoyé par zobal

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:

---

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 ?

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

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

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

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

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

Citation:

---

Envoyé par JolyLoic

Je peux le placer dans une searchHistory, le transmettre à un searchEngine et demander à ce dernier des searchResults...

---

Donc en gros pour simplifier :mrgreen:, 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 :mrgreen:: je m'en fiche du type parce que je vais juste passer "la patate chaude" à un autre objet.

Citation:

---

Envoyé par JolyLoic

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:

---

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

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

Citation:

---

Envoyé par Pyramidev

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

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

Les arguments sont intéressants, merci, c'est instructif et ça a tout son sens dans les exemples cités qui sont plutôt haut niveau.

Mais j'ai très rarement travaillé en C++ sur des applis haut niveau. A chaque fois il y avait un gros besoin en minimalisant le poids des livrables pour les cibles embarquées (mobiles / Raspberry / équipements industriels), économisant la mémoire (jusqu'aux échanges entre processeur / cache / et mémoire) et garantissant les performances ainsi que la conso réseau (surtout quand on est en 3G / 4G).

Quand c'est plus haut niveau (comme par exemple un moteur 2D / 3D), l'interface, l'ergonomie et les fonctionnalités utilisatrices sont déléguées à des technos plus haut niveau comme C#, Java ou via des modules Node, NDK ou tout simplement exploités par sockets.

A ce niveau d'exigence, on doit tout savoir sur chaque instruction commandée au dispositif.

En effet, les principales techniques d'optimisation reposent sur comment on utilise les choses. Par exemple on privilégiera un tableau de structures à une structure de tableaux, ou l'inverse, selon le cas d'usage qui lui est plus haut niveau. La cohésion est alors un peu pétée mais il y a des techniques pour contraindre l'utilisateur à l'utiliser de telle ou telle manière même s'il doit garder sa part de vigilance en fonction de comment sont faites les choses pour les exploiter au mieux, parfois même il devra adapter son organisation.

Pour l'alignement mémoire, c'est pareil. Est-ce que je dois faire

Code:

---

1 2 3 4 5 6 7 8 9

class A { public: .... private: auto titi A; auto tata B; }

---

ou

Code:

---

1 2 3 4 5 6 7 8 9

class A { public: .... private: auto tata B; auto titi A; }

---

Mais c'est super bandant ce genre d'évolution, peut-être qu'un jour le C++ pourra permettre de faire des choses haut niveau avec un seul de rentabilité équivalent à du Java ou du C# mais avec ses performances en plus.

C'est pourquoi le concept du "vol de mémoire" est pour moi la plus grande avancée du C++ ces dernière années. Pour le reste, c'est sûrement que ça me fait peur de ne pas avoir la pleine maîtrise de ce qui se passe à niveau matériel mais sur d'autres projets où c'est moins important, ça risque d'être vraiment pas mal ce mot clé "auto".

A bientôt et merci pour cet échange :)

Citation:

---

Envoyé par JolyLoic

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

---

Tu perds quand même une information à la relecture du code avec auto, c'est le type de la variable, là il faut deviner au moment de l'appel de la fonction. Tu peux parfois connaitre le type et ce que tu peux faire avec, dans ton cas pour faire pareil tu utilises une homonymie type/variable ?

La plupart du temps, j'essaye de trouver un nom qui définisse le rôle de la variable (password, plutôt que passwordString ou str). Mais il y a des cas où je n'y arrive pas (essayez de trouver un nom descriptif pour un itérateur!). Sans ce cas là, il y a homonymie non pas variable/type, mais plus variable/concept auquel répond le type.

Pour reprendre le cas de l'itérateur, je le nommerais plutôt it ou iterator que vector_of_string_iterator ou encore je nommerais une variable fileList même si son type est std::vector<std::string>.

D'ailleurs, à ce sujet, il y a eu des suggestions pour étendre les concepts à la déclaration de variables, histoire d'avoir un intermédiaire entre le type, trop précis, et auto, perçu par certains comme trop imprécis. On pourrait alors écrire Iterator it = v.begin();, le type de it serait déduit comme avec auto, mais ensuite, on vérifierait si ce type répond au concept Iterator, et si ce n'est pas le cas, on lèverait une erreur. Je ne sais pas trop si j'utiliserais une telle écriture si elle devenait disponible, ou si je resterais avec auto. Il faudrait que je l'expérimente dans la vraie vie.

Globalement, on y gagne à la relecture. Si le nom de la variable a du sens, on se pert difficilement. En tout cas dans mon expérience, utilise auto en vaut vraiment la peine. Et je fais aussi des softs dans lesquels on règle les perfs au nano poil de cul, ça n'y change rien, c'est quand même utile.

Citation:

---

Envoyé par mister3957

...

Pour l'alignement mémoire, c'est pareil. Est-ce que je dois faire

Code:

---

1 2 3 4 5 6 7 8 9

class A { public: .... private: auto titi A; auto tata B; }

---

ou

Code:

---

1 2 3 4 5 6 7 8 9

class A { public: .... private: auto tata B; auto titi A; }

---

...

---

Mais auto n'est pas utilisable dans ce cas. Il n'a strictement rien à voir avec quelconque problème de performance, conso, poids du livrable, quelque soit le niveau ni rien. Ce n'est qu'un sucre syntaxique. :weird: