C++17 - Genèse d’une version mineure

Auteurs olibre, duckie, rom1v, Oliver H, cracky, Lucas, palm123, Adrien Dorsaz, Martin Peres, RyDroid, Davy Defaud, ZeroHeure, Benoît Sibaud, tankey, Storm, M5oul et Anthony Jaguenaud
Licence CC BY-SA 4.0
URL https://linuxfr.org/news/c-17-genese-d-une-version-mineure
Date 2016-06-27T00:11:42+02:00 (création de la dépêche sur LinuxFr.org)
Tags c++, cpp et c++17
Score 60

La série de dépêches C++ continue. Cette seconde dépêche nous amène dans les réunions du comité de standardisation en vue de publier la prochaine version C++17 et nous permettra de vérifier ce titre provocateur (comment ça mineure ?). Cette dépêche peut intéresser tous les lecteurs de LinuxFr.org, pas seulement les développeurs. Les prochaines dépêches seront plus techniques.

Deux collègues discutent : « C++ est enfin sorti », « Trop top », « Va falloir se palucher les 1700 pages du nouveau standard », « Gloups ». Une note repositionnable sur le dessin indique : « Il y en a qui ne connaissent pas encore LinuxFr.org »

Dépêches C++

Cette dépêche est la deuxième d’une série de cinq dépêches sur le C++. La première dépêche Les coulisses du standard C++ a été publiée fin août dernier.

  1. La dépêche précédente, Les coulisses du C++, présente la naissance du langage, sa longue normalisation, sa spécification officielle non libre, payante, ouverte, délaissée au profit de son brouillon (draſt), peu lue par les développeurs C++…

  2. Cette dépêche, Genèse du C++17, raconte les dernières réunions du comité de normalisation et donne des éléments pour expliquer ce long processus de normalisation.

  3. La troisième dépêche, Nouveautés C++17 du langage, présentera les changements au niveau du langage : déduction des arguments template std::array a{1,2,3} ;, décomposition du retour de fonction auto [x,y]=f() ; , namespace aa::bb{} équivalent à namespace aa{namespace bb{}}, if constexpr sélectionne du code à la compilation, lambda constexpr, lambda capture *this, if(init;condition) comme for(init;cond;inc), variables inline… Mais il faudra encore attendre pour l’intégration des Concepts, Modules, Syntaxe d’appel uniforme et Réflexion.

  4. La quatrième dépêche, Nouveautés C++17 de la bibliothèque standard, présentera les changements au niveau de la bibliothèque standard qui pourraient bien bousculer notre petite vie de développeur : algorithmes parallélisés, std::string_view, std::filesystem, std::variant, std::any, std::optional, les fonctions spéciales mathématiques… Mais, les intervalles (ranges) et le réseau (networking) seront intégrés pour une version suivante du C++.

  5. Bilan C++17 et attentes pour C++20. Version mineure ou majeure ? D’un côté, les améliorations sont nombreuses et appréciables. Mais de l’autre, aucune fonctionnalité majeure n’est intégrée, exceptées celles qui sont déjà disponibles dans Boost. Cette cinquième dépêche s’attaquera aux questions existentielles du C++ : Quelles conséquences sur le processus de normalisation ? Qu’attendre de C++20 ? Intérêt du C++ aujourd’hui ? Quels langages alternatifs ? Que faire pour dynamiser l’évolution du C++ ? S’impliquer ?

  6. … d’autres dépêches à venir. :-)

Logo C++FRUG représenté par un gros "C++" au centre du cercle de la Francophonie

Partage

Chère lectrice, cher lecteur LinuxFr.org. Tu souhaites donner un coup de main pour les dépêches suivantes ? Rejoins‐nous dans l’espace de rédaction collaborative sur LinuxFr.org. Un compte est nécessaire pour y accéder.

Après publication, les dépêches sont figées sur LinuxFr.org. Alors, pour continuer à améliorer ce contenu libre (fôtes, oublis, franglais, maladresses…), n’hésite à pas à aller sur le dépôt Git C++FRUG. Tu y trouveras les versions de ces dépêches les plus à jour :

  1. Les coulisses du standard C++ ;
  2. Genèse d’une version mineure ;
  3. Nouveautés du langage ;
  4. Nouveautés de la bibliothèque standard ;
  5. Bilan et attentes pour C++20.

Avec toutes nos contributions réunies, nous profiterons davantage de nos découvertes individuelles et nous offrirons un contenu CC BY-SA de qualité pour créer, par exemple, des supports de formation (Meetups), des articles sur d’autres blogs… Par contre, pour le moment nous ne pouvons pas encore en faire profiter Wikipédia : notre dépêche étant en CC BY-SA version 4.0 et Wikipédia encore sur la version précédente :-/

Deux sommets pour délimiter le périmètre C++17

Comme le prévoit le cycle de publication triannuel, c’est en 2016 (année N-1) que le comité de normalisation du C++ vote le périmètre fonctionnel du C++17. Ainsi, les membres du comité se sont réunis à deux reprises pour intégrer de nouvelles fonctionnalités au C++ :

  1. Une semaine début mars, à Jacksonville (Floride), pour adopter beaucoup de fonctionnalités, mais aussi pour rejeter plusieurs fonctionnalités majeures très attendues ;
  2. Une semaine fin juin, à Oulu (Finlande), pour intégrer pas mal d’autres fonctionnalités et ainsi clore l’ajout des fonctionnalités.

La semaine se déroule sur six jours, du lundi au samedi. Pas de grasse matinée car les premières réunions débutent à 8h30. Ces réunions permettent de débattre et voter l’intégration de chacune des spécifications techniques (Technical Specification). Plusieurs réunions se déroulent en parallèle, et les membres rejoignent les réunions selon leur centre d’intérêt. Après ces réunions officielles, les membres se retrouvent pour continuer à échanger ou pour améliorer les spécifications techniques.

Mais à Oulu, un phénomène naturel a eu un impact direct sur la productivité : le soleil se couche après minuit en juin ! Si bien, que la plupart des membres ne se rendaient pas compte de l’heure et ont continué à bosser bien plus tard que d’habitude. En plus du soleil qui dort seulement deux heures par nuit, le décalage horaire (jetlag) a achevé les non-européens qui ont eu besoin de plusieurs jours de repos pour s’en remettre !

Voici à quoi ressemble le soleil à une heure du matin au mois de juin (ici c’est à Tromsø à 600 km de Oulu) Le soleil n'est pas encore couché à une heure du matin dans la ville de Tromsø à 600 km de Oulu

Des racines C++17 très profondes

Les membres du comité de standardisation C++ n’avaient pas pu intégrer toutes les fonctionnalités qu’ils souhaitaient dans C++11 car cela aurait retardé d’autant plus la publication de cette version (déjà que la publication était prévue avant 2010…). Les membres avaient donc décidé d’intégrer les fonctionnalités mineures dans C++14 et de continuer à mûrir les fonctionnalités majeures pour C++17.

Par conséquent, C++17 n’a pas commencé à être construit au lendemain de la publication de C++14, mais bien avant : certaines parties datent du début des années 2000 !

Analogie entre les fonctionnalités promises pour C++17 et les promesses des candidats à la présidentielle de 2017 en France

Plus de 10 ans pour intégrer les fonctionnalités

Effectivement, certaines fonctionnalités sont dans le tuyau depuis plus de dix ans :

Par contre, d’autres fonctionnalités majeures sont toujours dans le tuyau :

Comme quoi, le comité de standardisation prend son temps pour bien s’assurer que chaque fonctionnalité soit parfaite et cela peut prendre une dizaine d’années ! L’objectif étant de ne pas dégrader d’avantage la complexité inhérente au C++, avec comme contre partie d’avoir un langage de programmation qui évolue doucement…

Deux chatons déçus du contenu de C++17 "Sniff.. On n'a pas les Concepts. Ni la Réflexion."

Mais pourquoi autant de temps ?

Avant de répondre à cette question, voici un petit exercice. Il faut trouver la correction pour que le code C++ suivant compile :

struct MaClasse
{
  template <class T>
  void f() { }
};

template <class T>
void maFonction (T& t)
{
  t.f<int>();
  //  ^~~ expected primary-expression before 'int'
}

int main()
{
  MaClasse maclasse;
  maFonction(maclasse);
}

Quelques compilateurs en ligne pour tester tes idées :

Le message d’erreur du compilateur GCC : (le texte du message n’a pas changé entre GCC-4.4 et GCC-6.2)

$ g++ enigme.cpp
enigme.cpp: In function ‘void maFonction(T&)’:
enigme.cpp:10:12: error: expected primary-expression before ‘int’
     t.f<int>();
         ^~~
enigme.cpp:10:12: error: expected ‘;’ before ‘int’

Allez une grosse image pour ne pas être tenté de lire la réponse tout de suite.

logo "The C++ Programming Language"

Allez, deux indices : Primo, c’est du vieux C++98 (ne cherchez pas midi à C++14 heures) ; Secundo, ci-dessous le message d’erreur fourni par le compilateur Clang-3.8.

$ clang++ enigme.cpp                                                    
enigme.cpp:10:7: error: use 'template' keyword to treat 'f' as a dependent template name
    t.f<int>();
      ^
      template

Les plus rapides qui publient en commentaire une solution sans regarder la réponse ont gagné :-) Les vainqueurs auront le droit de poser en commentaire d’autres énigmes sur le thème des bizarreries du C++.

Encore une grosse image. On joue le jeu, on ne triche pas !

le texte "C++" sur un fond de type "écran du film Matrix" (Copyright webblaster48 2009 CC-BY-NC-ND-3.0)

Réponse

Il manquait juste le mot clef template à un endroit un peu inattendu :

struct MaClasse
{
  template <class T>
  void f() { }
};

template <class T>
void maFonction (T& t)
{
  t.  template  f<int>();
  // Oh le piège !
}

int main()
{
  MaClasse maclasse;
  maFonction(maclasse);
}

Cette syntaxe permet de dire au compilateur que T::f() est template quelque soit le type T (plus précisément, ici en absence du mot clef typename, le compilateur sait que c’est un appel à une fonction template). En effet, sans le mot clef template dans maFonction(), le compilateur ne peut pas être sûr que T::f() soit une fonction template. Le compilateur pourrait seulement s’en douter et le vérifier lors de l’instanciation de maFonction<MaClasse>()…

Avouons que ce n’est pas très joli joli, non ?

Ceux qui ont décidé de cette syntaxe doivent s’en mordre les doigts.

Mais revenons en à notre question, Mais pourquoi autant de temps ? L’hypothèse est que ce type de décisions du passé a traumatisé les membres du comité de normalisation du C++ : « ne recommençons pas les mêmes erreurs, ne nous précipitons pas, prenons le temps de bien mûrir les nouvelles fonctionnalités… »

Chère lectrice, cher lecteur de LinuxFr.org, à ton avis, pourquoi aussi peu de fonctionnalités majeures dans C++17 ?

En 2003, Bjarne Stroustrup propose la première version des Concepts. Ce "comic strip" imagine alors Bjarne demander l'intégration des Concepts pour chacune des versions de C++ : C++03, C++11, C++14, C++17... et à chaque fois les Concepts ne sont pas intégrés. Sur la dernière vignette, les Concepts sont enfin intégrés (de très nombreuses décennies plus tard). Sur cette dernière vignette est dessinée une pierre tombale avec une voix qui sort "Ce n'est pas trop tôt !".

C++1z ou C++17 ?

Historiquement, les versions C++ n’étaient pas publiées à date fixe. De plus, la version C++ qui devait suivre C++03 avait été reportée à maintes reprises. Cette version a été nommée temporairement C++0x. Et, finalement, C++0x a été publié en 2011 ! (mais bon en hexadécimal 0x = 11 est correct avec x = B)

Afin d’éviter tout nouveau glissement, le comité a alors décidé de publier un nouveau standard C++ tous les trois ans, en figeant les fonctionnalités l’année n - 1. Avec un cycle d’une version majeure (C++11) suivie d’une version mineure (C++14).

Malgré des dates de publication figées, les appellations C++1y (pour C++14) et C++1z (pour C++17) perdurent. Par exemple, l’option de compilation -std=c++1z ou l’étiquette c++1z sur stackoverflow.

Donc, C++1z est utilisé par les sceptiques pour désigner la version qui succédera à C++14. Et C++17 est utilisé pour désigner la version qui sortira en 2017.

Les membres du comité de normalisation utilisent le terme C++17 (et non pas C++1z). Soyons confiants, C++1z verra bien le jour en 2017 (et non pas en 2018, ni après).

La suite…

La prochaine dépêche va nous permettre d’entrer enfin dans le vif du sujet C++17.

Merci de nous donner un coup de main à la rédaction des prochaines dépêches C++17. Pour participer ou lire en avance les prochaines dépêches :

Droit d’auteur, licences, remerciements

Le texte de cette dépêche est protégé par le droit d’auteur la gauche d’auteur et réutilisable sous licence CC BY-SA 4.0.

Merci aux nombreux auteurs sur le dépôt Git et sur LinuxFr.org : olibre, duckie, rom1v, Oliver H, Benoît Sibaud, cracky, palm123, Lucas, Adrien Dorsaz, RyDroid, M5oul, Storm et Martin Peres. Cette dépêche fut commencée en juin 2016 et contient plus de 1300 révisions !

Merci à Klaim, Édouard A, rewind, et gasche pour leurs commentaires pertinents.

Merci à mes collègues développeurs qui, à défaut de m’aider à la rédaction, ont illustré cette série de dépêches avec des dessins humoristiques sous licence libre :

Et merci à ceux qui permettent de réutiliser leur travail :

Merci d’avance de l’aide apportée sur les prochaines dépêches C++17 en cours de préparation : Micka pour ses exemples utiles et AMB007 pour les bogues trouvés dans les codes C++ d’exemple.