Compte rendu du meeting C++ à Kona
Le 28/10/2015, par Aurelien.Regat-Barrel, Expert éminent sénior
Le meeting C++ est terminé et je m'aventure à donner une liste non exhaustive de papiers qui ont passé la cap de la proposition pour aller dans Core (afin d'étudier leur intégration au standard):
- Variables inline (N4424)
- ajout de __has_include (P0061R0)
- noexcept intégré au type des pointeurs de fonction (au même titre que const / volatile) (P0012R0)
- construction d'un strong enum type sans faire un cast (p0138r0). En fait je découvre qu'on peut déjà en C++11 faire un strong typedef sur un type intégral de cette manière:
ce papier permet de simplifier l'utilisation d'un tel type en supprimant la nécessité de la caster à l'initilisation
- spécification de l'ordre d'évaluation des arguments d'une fonction (n4228 révisé) => f(a, b, c) évaluera a, b, c dans cet ordre là. Apparemment, la norme ne spécifiait pas d'ordre pour permettre aux compilos une éventuelle optimisation qui en pratique n'aurait été implémentée nulle part.
- utilisation des lambdas en tant que constexpr (n4487)
- moins de restrictions sur l'initialisation des types agrégés (p0017r0) - cela permet de se passer d'écrire un nouveau constructeur quand une struct hérite d'une autre struct
- constexpr if (p0128r0) cela semble bien ressembler au static if de D. Dans le papier il est mentionné un mot clé spécifique (constexp_if) mais ce dernier point a été rejeté
- rendre "officielle" l'élimination de la copie des objets dans certains cas : typiquement une variable locale qui est renvoyée / lancée sous forme d'exceptions (p0135r0) - cela permet d'écrire un code légal qui s'attend explicitement à cette optimisation (donc sans constructeur de recopie)
voilà en aperçu. A noter que cela ne veut pas dire que ces changements seront dans C++17, mais qu'ils ont été acceptés pour y être intégrés si le groupe spécialisé dans cette tâche n'identifie pas de problème.
Enfin, deux papiers importants acceptés pour devenir des TS:
- modules
- STL range ! J'ai pu faire une interview d'Eric Niebler à ce propos
En tous j'ai pu faire une dizaine d'interviews, qui seront publiées au fur et à mesure (vous pouvez vous inscrire à la mailinglist ici si ça vous intéresse). En particulier, j'ai pu échanger avec Jean-Paul Rigault, un des rares français à avoir participé à la première norme de C++ et qui continue encore à suivre l'évolution du langage aujourd'hui.
Et vu qu'on commence à être un certain nombre à s'intéresser de près à l'évolution du langage, on pourrait peut-être voir pour monter un groupe dédié au sujet ? Car c'est comme cela qu'avait commencé la participation de la France il y a plus de 15 ans déjà !
- Variables inline (N4424)
- ajout de __has_include (P0061R0)
- noexcept intégré au type des pointeurs de fonction (au même titre que const / volatile) (P0012R0)
- construction d'un strong enum type sans faire un cast (p0138r0). En fait je découvre qu'on peut déjà en C++11 faire un strong typedef sur un type intégral de cette manière:
| Code : |
enum class Index : uint32_t { }; // aucun enum !
- spécification de l'ordre d'évaluation des arguments d'une fonction (n4228 révisé) => f(a, b, c) évaluera a, b, c dans cet ordre là. Apparemment, la norme ne spécifiait pas d'ordre pour permettre aux compilos une éventuelle optimisation qui en pratique n'aurait été implémentée nulle part.
- utilisation des lambdas en tant que constexpr (n4487)
- moins de restrictions sur l'initialisation des types agrégés (p0017r0) - cela permet de se passer d'écrire un nouveau constructeur quand une struct hérite d'une autre struct
- constexpr if (p0128r0) cela semble bien ressembler au static if de D. Dans le papier il est mentionné un mot clé spécifique (constexp_if) mais ce dernier point a été rejeté
- rendre "officielle" l'élimination de la copie des objets dans certains cas : typiquement une variable locale qui est renvoyée / lancée sous forme d'exceptions (p0135r0) - cela permet d'écrire un code légal qui s'attend explicitement à cette optimisation (donc sans constructeur de recopie)
voilà en aperçu. A noter que cela ne veut pas dire que ces changements seront dans C++17, mais qu'ils ont été acceptés pour y être intégrés si le groupe spécialisé dans cette tâche n'identifie pas de problème.
Enfin, deux papiers importants acceptés pour devenir des TS:
- modules
- STL range ! J'ai pu faire une interview d'Eric Niebler à ce propos
En tous j'ai pu faire une dizaine d'interviews, qui seront publiées au fur et à mesure (vous pouvez vous inscrire à la mailinglist ici si ça vous intéresse). En particulier, j'ai pu échanger avec Jean-Paul Rigault, un des rares français à avoir participé à la première norme de C++ et qui continue encore à suivre l'évolution du langage aujourd'hui.
Et vu qu'on commence à être un certain nombre à s'intéresser de près à l'évolution du langage, on pourrait peut-être voir pour monter un groupe dédié au sujet ? Car c'est comme cela qu'avait commencé la participation de la France il y a plus de 15 ans déjà !