Avec un peu de retard, mais c’est pas grave, nous avons initié le projet de présenter les nouveautés de C++17. Toute personne intéressée peut faire des suggestions ou rejoindre la rédaction. Pour l’instant, il y a @gbdivers, @lmghs, @germinolegrand, @mehdidou99, @jo_link_noir et moi-même.
Nous sommes encore en train de réfléchir à un plan, donc ne vous étonnez pas de voir l’article vide. Plutôt que de partir sur une énumération des drafts, nous cherchons une façon de présenter par thème, ou regroupement, qui mettra plus en valeur les évolutions, en présentant la situation avant et ce que la nouveauté résout ou améliore.
Voici les messages échangés en privé avant que cet article soit créée :
Salut à tous,
Suite à une idée de @mehdidou99, on s’est dit que ZdS a un article sur les nouveautés de C++14 mais pas C++17. On a donc eu l’idée de réunir la team C++ pour vous proposer d’écrire un article ensemble, même s’il a un an de retard.
J’ai fait un billet sur les structured bindings parce que c’est compliqué à traiter au milieu d’un article.
germinolegrand
A mon avis, si c’est possible (si on a le temps et la motivation), il faut structurer et presenter les choses différement de ce qui a deja ete publié, pour que cela puisse avoir une vraie plus-value.
Il faut commencer par organiser l’article en 3–4 parties, en regroupant les ajouts par theme, plutot que de simplement lister les ajouts par draft. Il faudrait que 1 personne écrive une structure de l’article avec un tel decoupage. Ca serait ensuite plus simple pour qu’on puisse travailler sur des parties independantes.
Je peux refaire une mise a jour de mes sources, pour voir les sources plus recentes ou les sources sur des drafts particulier. (En particulier avec les videos de le CppCon 2018 qui sont entrain de sortir). Et trier les sources par drafts.
Ce qui serait le plus interessant (mais cela demande plus de travail) serait de ne pas simplement repondre a la question "quelles sont les nouvelles syntaxes ?", mais pour chaque syntaxe :
quelle est la problématique ?
quelles sont les solutions en C++98/03/11/14 ?
quelle est la nouvelle solution en C++17 ? Pourquoi elle est mieux/complementaire ?
(optionel : qu’est-ce qu’on aura en C++20 sur cette problématique ?)
Il y a encore beaucoup de gens qui n’ont pas compris le pourquoi/comment des evolutions du C++, ce genre d’approche peut aider a faire le pas.
gbdivers
Si on prend les ajouts, on peut déjà diviser ceux qui concernent le langage lui-même et ceux qui sont des ajouts à la bibliothèque standard, même si je ne sais pas si ce découpage est le plus pertinent.
Si on regarde les ajouts qui permettent d’être plus concis, on a ceux-là.
Ensuite on a les ajouts type safe comme std::variant, std::byte, std::any, std::optional.
Ensuite on peut parler des templates, avec utilisation de auto, de constexpr if et constexpr lambda, folding expressions, nouvelles règles de déduction pour auto.
Enfin, on parle du reste, comme le std::filesystem, et on met des liens et tout ça. Une partie en mode « Le reste » pour y mettre tout ce qui ne rentre pas directement dans les autres thèmes.
Qu’en dites-vous ?
informaticienzero
Le découpage par fonctionnalités est classique, mais je trouve que cela fait trop catalogue de syntaxes. On peut proposer cette organisation, c’est ce qu’il y a de plus simple. Mais c’est aussi celle que tout le monde fait (a fait).
C’est pour cela que je préfère une présentation orienté selon les problématiques des utilisateurs.
Pour être concret sur les 4 exemples que tu cites :
Ensuite on a les ajouts type safe comme std::variant, std::byte, std::any, std::optional.
On a a priori des fonctionnalités qui concernent des domaines complètement différent :
optional va etre plus pour la gestion des retours de fonctions et des "erreurs"
variant et any seront plus orienté vers la programmation générique (type erasure)
byte est plus orienté gestion de la mémoire et programmation embarqué
Si on regarde les autres proposals, on pourrait par exemple, en conservant ces 3 domaines :
optional pourrait etre regroupé avec les exceptions (P0012R1), static_assert (N3928), maybe_unused (P0212R1), les structured bindings (P0217R3), etc.
variant et any pourrait etre regroupé avec les fold expressions (N4295), auto, template, etc.
byte pourrait etre regroupé alors l’alignement en memoire (P0035R4)
Et il est alors facile d’introduire ces différents domaines en présentant les problématiques, les grandes questions, les solutions proposées dans les précédentes versions du C++, et ce que propose le C++17 :
comment gérer les erreurs en C++ ? Les code d’erreur vs les exceptions vs retourner un objet invalide. Vs optional avec le C++17.
comment etre efficacement fainéant ? L’intérêt de la programmation générique, les templates, la déduction de type, void*, les variadics function/template. Ce qu’apporte any/variant, ce qu’apporte les fold ?
comment faire du bas niveau safe en C++ ? Cf les CppCon sur l’embarqué en C++. Interet de byte.
Ce type d’approche pour présenter les choses permet au lecteur de plus facilement de :
faire le lien avec ses connaissances actuelles (donc facilité la mémorisation)
mettre a jour ses connaissances sur ce qu’il a loupé dans le C++11/14 (ou ce qu’il a loupé dans les bonnes pratiques)
pousser a se poser des bonnes questions sur sa pratique
Je sais que cela demande plus de boulot de faire comme cela. Mais vu qu’on a déjà 1 an de retard, autant prendre son temps pour essayer de proposer autre chose.
gbdivers
Je n’aime pas mélanger optional et les erreurs. C’est du patch dégueulasse en attendant expected. L’optionalité d’une information et les erreurs mixées sur les canaux de retours, sont deux choses sémantiquement différentes. Si aujourd’hui beaucoup semblent vouloir vendre optional selon l’angle des erreurs, dans 2 ans (maintenant), on va voir apparaître des "arrêtez d’utiliser optional pour ça", de la même façon que dès que le C++11 est sorti, on a commencé à faire la chasse aux shared_ptr. Et si on anticipait? Ou alors, il faut écrire en clair: "attention cette pratique n’est bonne qu’en C++17 uniquement, elle sera dépréciée dans 2 ans en C++20!"
Sinon, +1 au regroupement selon les besoins./domaines.
Côté efficacité & cie, j’ai exploré l’angle : patch des futures, tailles des lignes de caches, algos parallèles — avec le problème que ni GCC/libstdc++8.2, ni LLVM/libc++ 6 (je n’ai pas encore installé le 7) ne supportent la moitié des évolutions. AMA, c’est l’apport le plus important en termes de fonctionnalités du C++17. Le reste visant plus à apporter des simplifications ou à entériner des choses incubées dans boost — d’où le ressenti général que le C++17 n’a pas été une évolution "majeure".
Mais aussi constexpr qui est de mieux en mieux supporté (std::begin, std::distance, lambdas…).
A propos de if constexpr, c’est bien gentil, c’est "facile" à utiliser, mais ce n’est pas compliant avec l’OCP: au lieu de plugguer une nouvelle spécialisation (/point de variation) dans une zone commune (communality), on doit aller modifier toute occurrence de if constexpr pour ajouter le nouveau cas. Par contre, il y a moyen de simplifier des messages de meta-programmation — cf je ne sais plus qu’elle présentation récente.
lmghs
Je n’aime pas mélanger optional et les erreurs. C’est du patch dégueulasse en attendant expected. L’optionalité d’une information et les erreurs mixées sur les canaux de retours, sont deux choses sémantiquement différentes. Si aujourd’hui beaucoup semblent vouloir vendre optional selon l’angle des erreurs, dans 2 ans (maintenant), on va voir apparaître des "arrêtez d’utiliser optional pour ça", de la même façon que dès que le C++11 est sorti, on a commencé à faire la chasse aux shared_ptr. Et si on anticipait? Ou alors, il faut écrire en clair: "attention cette pratique n’est bonne qu’en C++17 uniquement, elle sera dépréciée dans 2 ans en C++20!"
Pour cela que j’avais mit des guillemets sur "erreurs"
Je suis d’accord avec toi pour ne pas confondre optional et la gestion des erreurs. Les objectifs et outils sont differents. J’en parle souvent ensemble dans l’idée de "comment une fonction peut se terminer". Et aussi parce que, en cas d’erreur, on peut vouloir retourner une valeur ou un objet qui correspond a "rien" (nullptr, objet invalide, etc). Et dans ce cas, optional peut etre une alternative (objet qui peut etre invalide VS optional + objet qui ne peut pas etre invalide).
gbdivers
Dans mes formations, j’ai un court chapitre qui se résume à comme remplacer T* f() et void f(T*) par quelque chose de plus parlant sur les plans sémantiques, de plus robuste, de moins équivoque, etc.
Et j’y introduis, et insiste ainsi sur, unique_ptr, les références, et optional. Selon le public, j’évoque aussi gsl::not_null en alternative aux références, et critique le style proposé par les C++CoreGuideline où T* est une _non onwing` view — ça, je n’aime vraiment pas, car cela suppose que tous les dévs aient migré dans un style moderne, chose qui est totalement utopique.
lmghs
Je suis de l’avis de @lmghs, c’est une mauvaise idée de présenter std::optional comme système d’erreur. L’objectif est même contradictoire, une valeur optionnelle est un état explicitement accepté et prévus alors qu’une erreur est avant tout un imprévu. Même si pour un retour de fonction la différence peut devenir flou.
Au niveau des thématiques je vois:
any, variant et optional pour une autre manière de stocker/retourner/transmettre une valeur. À comparer avec void*, union, T*
Les simplifications effectuées sur la programmation générique:
pour les utilisateurs: guide, template auto, std::size/data
pour les développeurs: fold, les nouveaux traits, if constexpr
Les changements de comportement et les ajouts syntaxiques (objectif concision et simplification du code):
référence en retour de emplace/push
distinction du type des itérateurs de début/fin dans une boucle sur intervalle
…
Les fonctions d’optimisation et changement qui vont dans ce sens: to_chars, from_chars, string_view, future, alignement sur new, pmr, etc
Les autres comme filesystem, les nouveaux algos, etc que je ne sais pas vraiment classer.
jo_link_noir
(Je sens que j’aurais du faire un effort pour trouver un autre terme que "erreurs"…)
En tout cas, cette discussion confirme que c’est important de replacer les nouvelles syntaxes dans un contexte et des bonnes pratiques. Même si c’est dur, du fait qu’on manque de recul.
(A noter que cela ne me choquerait pas que l’on parle d’une meme feature 2 fois, dans 2 domaines d’application differents. Si on presente bien les choses)
Les autres comme filesystem, les nouveaux algos, etc que je ne sais pas vraiment classer.
A mon avis, ce sont des parties suffisament volumineuse et indépendantes pour faire l’objet de chapitres dediées.
Je vais faire un premier tri des proposals par categories et regrouper les sources en fonction de cela. Ca permettra d’avoir une vue d’ensemble et voir ce qui n’est pas encore correctement classé.
EDIT : il y a peut etre d’autres personnes sur le discord NaN ou sur le forum OC qui serait interessant d’inviter dans cette conversation. (Pour cela que j’edite sur mon GitHub, c’est public). Voire passer cette conversation sur le forum en public ? (Ou creer l’article et le passer en beta pour qu’il soit public)
