Discussion :

[LittleWhite]

C++14 : le draft final a été publié
Découvrez son contenu

Le draft final de la nouvelle version du C++14 est publié. La seconde bonne nouvelle, c'est que les compilateurs les plus utilisés supportent déjà cette nouvelle version. Voici ce qu'elle nous apporte :

• N3323 - Correction de certaines conversions contextuelles du C++ : améliorations du comportement de conversion à un unique opérateur, alors que la conversion d'une valeur de la classe vers le type spécifié par le contexte est possible ;
• N3472 - valeurs binaires : vous pouvez maintenant écrire des valeurs binaires telles que char c = 0b01011010 ;
• N3531 - valeurs définies par l'utilisateur pour les types standards : Unité de temps SI.
  

  Code :

  Sélectionner tout - Visualiser dans une fenêtre à part

  auto d = 2h + 5s + 234ms; // d est une durée de 2 heures, 5 secondes, et 234 millisecondes

• N3638 - decltype(auto) && déduction du type de retour pour les fonctions normales : decltype(auto) devient légal en C++. Le type de retour peut être déduit à partir de la valeur de retour. Cela résout les problèmes de déduction dans les fonctions récursives et le retour de référence ;
• N3648 - Capture de variables initialisées dans les lambdas : vous pouvez capturer des variables initialisées ou non initialisées :

  Code :

  Sélectionner tout - Visualiser dans une fenêtre à part

  1
  2
  3
  4
  5
  int x = 4;
  auto y = [&r = x, x = x+1]()->int { 
      r += 2;
      return x+2;
  }(); // Met à jour ::x à 6, et initialise y à 7.

• N3649 - Expression (polymorphique) générique pour les lambdas : permet à un lambda d'utiliser auto comme spécificateur de type dans la déclaration des paramètres : auto add = [](auto a,auto b){return a + b;} ;
• N3651 - Variables templates : une variable peut maintenant être un template :

  Code :

  Sélectionner tout - Visualiser dans une fenêtre à part

  1
  2
  template<typename T>
  constexpr T pi = T(3.1415926535897932385);

• N3652 - Soulagement des prérequis pour les fonctions contexpr : vous pouvez dorénavant utiliser une fonction contexpr qui n'est pas statique ou thread_local, utiliser if (else/if else) et switch (mais pas goto), utiliser des boucles, des objets dont le temps de vie démarre dans l’évaluation contexpr et qui peut changer ;
• N3653 - Initialiseurs de membre et regroupement : vous pouvez maintenant utiliser les accolades d'initialisation dans le regroupement de membres d'un tableau ;
• N3664 - Clarification des allocations de mémoire : reformulation des explications de l'allocation de mémoire du standard ;
• N3760 - [[deprecated]] : nouvel attribut pour signaler un élément déprécié ;
• N3781 - Séparateur de chiffre : le ' peut être utilisé comme séparateur dans les nombres : 1'000'000 ;
• N3778 - Opérateur global de déallocation avec une indication de taille : le C++11 apportait un opérateur de déallocation ayant un opérateur de taille, mais un tel opérateur n'était pas global. C'est maintenant corrigé.
• make_unique : vous pouvez dès à présent faire toutes vos allocations de mémoire sans jamais utiliser directement new et delete.

Durant la dernière rencontre à Issaquah, les éléments suivants ont été discutés :

• N3887 - Alias de méta-fonction consistent : les méta-fonction devait avoir un nommage consistent et seul l'élément tuple_element_t manquait dans le standard. C'est corrigé dans le C++14 ;
• N3891 - Renommage de shared_mutex en shared_timed_mutex : afin d'éviter un possible conflit de nom, le shared_mutex a été renommé en shared_timed_mutex ;
• N3910 - Que peuvent faire les gestionnaires de signaux ? : clarification des termes des gestionnaires de signaux du standard C++ ;
• N3924 - Utilisation de rand découragée en C++14 : Rien n'a été déprécié dans le C++14 à l'aide du nouvel attribut. Un des bons candidats serait rand qui n'est pas déprécié (simplement marqué pour être déprécié), par contre std::random_shuffle l'est ;
• N3927 - Définition de lock-free : reformulation afin de gagner en précision de la définition de lock-free.

Votre opinion

Quelles sont les choses que vous attendiez le plus ?
Quelles sont les éléments que vous auriez voulu voir dans cette version ?


Source

Billet

[Arzar]

Bonjour,
Une autre petite amélioration de la STL C++14 très appréciable :
N3531 - User-defined Literals for Standard Library Types (version 3) : Unité de temps SI.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

auto d = 2h + 5s + 234ms; // d is a duration of 2 hours, 5 seconds, and 234 milliseconds

[ternel]

Je suis peut-être bigleux, mais je n'ai pas trouvé le draft lui-même.

Où peut-on le trouver?

[LittleWhite]

Merci
C'est tout de même très lié aux valeurs binaires, si je comprend bien.

[Ubiquité]

Quelles sont les choses que vous attendiez le plus ?

Ce que j'attendais le plus c'est pouvoir écrire des nombre binaires en binaires, je comprend pas d'ailleurs pourquoi c'était pas là avant, ca devait pas être très très compliqué à implémenter.
Mais ca fait plaisir aussi de pouvoir utiliser les expression génériques pour les lambdas, le make_unique, et que ce soit beaucoup plus simple d'avoir une fonction constexpr !

[Luc Hermitte]

Ce que j'attendais. make_unique, lambda génériques, le relâchement des contraintes pour l'écriture de fonctions constexpr , la syntaxe étendue pour les initialiseurs de membre et regroupement,

Ce que j'aurai voulu vu voir: n4075 sur la programmation par contrat. Mais visiblement, le sujet n'est pas abandonné même si cette forme l'a été -> n4110, une étude de Andrzej Krzemieʼnski (je donne les liens ici: http://luchermitte.github.io/blog/20...2014-ou-2017-p ). Et sur le sujet, j'aurai bien aimé que vector::operator[] requière un assert() sur ces préconditions ; en fait: j'aimerai que toutes les préconditions exprimées dans la norme soit doublées d'assertions -- si le n4075 était passé, cela aurait été STD_ASSERT_CONTRACT() plutôt qu'assert(), mais l'idée est la même. Certes, il y a les SL checkées, mais ce n'est pas standardisé et la forme varie dans mes souvenirs (IIRC, VC++ lance des exceptions (il faudrait que je vérifie)).

[Xiz0r]

Tous n'est pas encore implémente sur GCC.... ;(

https://gcc.gnu.org/projects/cxx1y.html

[Markand]

Les user defined literals font parti de mes chouchous avec l'ajout de standard pour l'unité de temps c'est vraiment génial

Celui que j'attendais avec impatience était le std::make_unique afin de ne plus avoir aucun new dans mon code.

Je suis aussi content de plus avoir à utiliser la new return value syntax et pouvoir juste utiliser auto pour la déduction du retour de type.

[Uther]

Je ne suis qu'un utilisateur ponctuel de C++, mon avis n'est peut-être pas représentatif, mais je trouve que le fait de pouvoir utiliser auto presque partout est plus un problème qu'une amélioration. C'est vrai que rien n'oblige a l'utiliser et qu'on a déjà tous les outils possibles en C++ pour faire du code dont le fonctionnement n'est pas évident, mais je me serait passé d'ajouter celui là.

[gb_68]

Je ne suis pas non plus particulièrement fan d'un "Presque Toujours Auto", mais cette idée fait son chemin aaa style : almost always auto.

Pour autant la présence d'un auto - déduction automatique du type - devenait une quasi nécessité dans beaucoup de cas (types définis par l'implémentation) et une simplification bienvenue dans d'autres, même si elle pose d'autres problèmes notamment avec les expressions templates (problème non trivial encore non résolu n4035 - vous saviez que l'on a de telles célébrités sur notre forum ).


On ne peut donc blâmer son existence.


Les derniers ajouts répondent aussi à des besoins importants : enfin des lambdas polymorphiques et une déduction du type de retour "différée".

Ce dernier point à des avantages qui n'apparaissent pas immédiatement, mais bien utiles try{stupid name lookup tricks for c++11 }catch(const head_explosion &){ /*TODO*/ }

[JolyLoic]

J'ai commencé à me mettre à "AAA", pour voir ce que ça donne, et l'impression que j'en ai pour l'instant, c'est que ça améliore plutôt la lisibilité quand le reste du code est bien écrit (par exemple, on a plein de vieux code qui prend une valeur de retour en argument par référence, et là, ça reste lourd). Mais je n'ai pas encore assez de recul pour donner un avis définitif.

[r0d]

J'ai commencé à me mettre à "AAA", pour voir ce que ça donne, et l'impression que j'en ai pour l'instant, c'est que ça améliore plutôt la lisibilité quand le reste du code est bien écrit (par exemple, on a plein de vieux code qui prend une valeur de retour en argument par référence, et là, ça reste lourd). Mais je n'ai pas encore assez de recul pour donner un avis définitif.

Je me suis mis également au "AAA", et passé les premiers écueils (par exemple l'utilisation de auto&), pour l'instant je ne vois que du positif.

[Invité]

Je m'attends à une séries de joies dans l'avenir du c++, quand j'ai vu cet article je me suis dis cool!

Le c++11 m'a tellement aidé (surtout au niveau de la méta-programmation) et m'a permis de pouvoir me débarrasser de certaines bibliothèques. (Il faut dire que le c++11 intègre une grosse partie des fonctionnalités de cette bibliothèque)
C'est entre autre grâce au c++11 et au c++14 que j'ai pu faire un système de sérialisation de manière simple et rapide avec mon framework.

Bref cette norme est géante grâce aux template variadiques entre autre et aux classes de traits. (Même si la syntaxe reste assez complexe, au début je n'avais pas l'habitude d'utiliser des structures plutôt que des boucles pour itérer mais avec l'habitude on s'y fais vite!)

Le c++14 semble être une amélioration syntaxique du c++11 plutôt que une intégration de nouveautés, moi ce que j'attends surtout c'est de voir comment va évoluer cette syntaxe! (Et de voir si il y aura encore des nouveautés énormes comme celle des variadique template.)

Un système de macro évolué qui nous permettrai d'exporter les macros en dehors d'une bibliothèque, modifier les .h et pouvoir recompiler la bibliothèque par exemple. (Bien que je pense que ça doit déjà être possible de le faire avec des bibliothèques dynamique.)

Bref je suis impatient de voir ce que ça va donner au niveau de la méta-programmation dans le futur.

[ternel]

Si tu fais référence à Boost, il ne faut pas rechigner à l'utiliser, vu qu'elle constitue en quelque sort la préversion de la future norme.
Il faudrait la considérer comme la "vraie" bibliothèque standard.

[oodini]

C++15, finalement ?...

[JolyLoic]

Non, C++14, même si la publication a effectivement eu lieu en 2015 (la version finale, qui a été publiée, avait été envoyée à l'ISO le 7 octobre, et ils mettent un peu de temps à publier).

Il est disponible (à un prix prohibitif) là : http://www.iso.org/iso/home/store/ca...csnumber=64029
Quand il sera publié sur le site Ansi, peut-être que le prix sera plus raisonnable. Mais on peut comme toujours trouver sans soucis des versions préliminaires gratuitement.