Discussion :

[Stéphane le calme]

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

[mister3957]

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

[Gugelhupf]

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

[mintho carmo]

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.

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 ?

[foetus]

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.

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.

[jo_link_noir]

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.

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.

[Pyramidev]

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

[zobal]

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.

[mister3957]

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

[Ehonn]

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

[mister3957]

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