IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Compte rendu du meeting C++ à Kona

Le , par Aurelien.Regat-Barrel

0PARTAGES

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:
Code : Sélectionner tout
enum class Index : uint32_t { }; // aucun enum !
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à !

Une erreur dans cette actualité ? Signalez-nous-la !