C++0x : le Draft final a été voté !

**befalimpertinent** · 12/01/2011, 17h53

Un interview de BS sur la prochaine norme (vote final le 26 mars):
http://www.codeguru.com/cpp/misc/art...Stroustrup.htm
(en anglais évidemment)

**Emmanuel Deloget** · 13/01/2011, 10h03

Si tout est fixé (à peu de chose près), il ne reste plus qu'à attendre un support décent de la part des compilateurs.

Une nouvelle ère s'offre à nous !

**oodini** · 08/02/2011, 23h25

Vous savez si cette nouvelle norme offrira un mécanisme similaire à final en Java ou sealed en C# ?

**Arzar** · 09/02/2011, 01h01

Bonsoir,
Et bien justement oodini, l'addition des mots clés final et override a été voté dans le tout dernier draft ! (N3225 - novembre 2010)

Et d'ailleurs je ne peux pas m'empêcher d'être un tantinet inquiet

A seulement quatre mois du vote final (prévu en mars) je ne pensais pas que le comité rajouterait encore de nouveaux mots clés (context-sensitive en plus!).

**Jean-Marc.Bourguet** · 09/02/2011, 08h59

Envoyé par Arzar

Bonsoir,
Et bien justement oodini, l'addition des mots clés final et override a été voté dans le tout dernier draft ! (N3225 - novembre 2010)

Et d'ailleurs je ne peux pas m'empêcher d'être un tantinet inquiet

A seulement quatre mois du vote final (prévu en mars) je ne pensais pas que le comité rajouterait encore de nouveaux mots clés (context-sensitive en plus!).

La fonctionalite etait deja presente dans les drafts precedants (avec des attributs), mais ca posait des problemes. L'utilisation de mots cles est la pour resoudre ces problemes.
(Et si j'ai bien suivit, ca sera encore modifie).

**Klaim** · 09/02/2011, 19h09

Oui le souci c'était qu'ils étaient parti du principe que c'était des "attributs" qui sont censés être des indications spéciales pour le compilateur et qui n'étaient pas censé changer la sémantique de l'expression.

Or comme ils les changent -- et que les attributs sont très moches a écrire et lire -- finalement ça a été remis en question. Dans les derniers votes (il me semble qu')ils ont décider de virer les attributs et tout simplement de prendre ceux qui étaient "demandés" comme de nouveaux mots clés.

Par contre ça serait bien qu'ils mettent quelque part de visible les raisons qui ont poussé à ajouter final et override. C'est pas toujours évident pour un développeur C++...

**JolyLoic** · 09/02/2011, 21h23

Le final, j'avoue ne pas trop voir ca que ça apporte. Le override, par contre, c'est la meilleure invention depuis l'eau chaude

En gros, ça assure la fiabilité du code en cas de refactoring.

Cas réel, bien que datant un peu :
On a du code :

Code :

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

1
2
3
4
5
6
7
8
9
class A
{
  virtual int f(char *s);
};
 
class B : A
{
  virtual int f(char *s);
}

Sauf que bien entendu, A et B n'étaient pas au même endroit, pas gérés par les mêmes personnes, et qu'en fait B n'était pas une classe, mais une vingtaine de classes (et pour la plupart de ces classes, f n'était pas redéfinie, le comportement de la classe de base étant convenable). Puis un jour, voulant appeler a->f("toto"), je "corrige" le bug du code initial :

Code :

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

1
2
3
4
class A
{
  virtual int f(char const *s);
};

Sauf que sur une des classes B, ce petit mot const n'a pas été reporté. Du coup, pour ces objets, quand on appelait f, on obtenais le f de la classe de base, pas celui au comportement légèrement différent de la classe dérivée. Et la différence de comportement était assez faible pour que le debug de ce qui se passait mal ait été long, très long...

Avec override, à la recompilation, le responsable de la classe B aurait eu une erreur, et le problème aurait été corrigé immédiatement.

**Klaim** · 10/02/2011, 12h00

J'imagine qu'override corrigera aussi la pratique que j'ai vu souvent d'utiliser virtual dans les surcharges pour se souvenir que c'est une fonction surchargée...

Ce qui est a mon avis très mauvais pour la compréhension, mais override corrige le problème effectivement.

Concernant final, je vois où ça peut être intéressant, mais seulement au niveau de la classe (ce qui ne sera pas dispo dans c++0x si je ne me trompe pas?). Donc autrement dit, un "sealed".

Quand on construit un type de manière a ce que l'heritage devienne dangereux (et donc déconseillé), je me dit que dire explicitement qu'on ne veut pas d'heritage du tout est plus efficace, même si il serait de bonne pratique de ne pas supposer de la manière d'utiliser la classe, sauf si on le sait pertinemment, comme pour les conteneurs de la STL.

**oodini** · 10/02/2011, 14h10

Envoyé par JolyLoic

Le final, j'avoue ne pas trop voir ca que ça apporte.

Empêcher de dériver de classes sans destructeur virtuel, et se reposer sur le polymorphisme (mauvaise idée, je sais, mais on ne maitrise pas toujours les codeurs qui passent derrière nous).

**Klaim** · 10/02/2011, 15h05

Envoyé par oodini

Empêcher de dériver de classes sans destructeur virtuel, et se reposer sur le polymorphisme (mauvaise idée, je sais, mais on ne maitrise pas toujours les codeurs qui passent derrière nous).

Autrement dit, pour rester "positif", mieu vaut conisidérer ça comme une manière de communiquer nos intentions aux futurs mainteneurs du code en question

**oodini** · 11/02/2011, 11h48

Existe-t-il une liste (ou mieux, une matrice) des bibliothèques Boost qui ont été incluses dans cette nouvelle norme ?

Invité · 11/02/2011, 12h55

Directement sur le site de boost, il y a onglet indiquant les bibliothèques incluses dans le TR1 et donc dans la prochaine norme : http://www.boost.org/doc/libs/?view=filtered_std-tr1. Par contre les fonctionnalité qui ont été incluses directement dans le langage(je pense notament à auto) ne sont pas répertoriées.

**Arzar** · 25/03/2011, 19h57

THIS IS IT !!

Howard Hinnant, le président du Library Working Group du comité C++ vient de lâcher le morceau sur Stack Overflow !!

Le draft final est terminé !!

Il sera rendu officiel et public le 13 avril. Pour compléter le processus ISO il reste encore quelques formalités administrative mais c'est une étape purement bureaucratique, car du point de vue technique c'est fini !

**JolyLoic** · 25/03/2011, 23h52

Zut tu m'as grillé, je voulais faire l'annonce en quasi direct, je n'aurais pas du aller fêter ça au resto avec les autres...

On a effectivement voté pour que la version du draft après les modifications de cette semaine soit proposée comme la nouvelle version du C++. Ça peut prendre un temps indéterminé à finaliser, mais on (Herb, en particulier) tente de faire ce qu'on peut pour accélérer la partie administrative.

Ps : Howard n'est plus en charge du library working group depuis un peu plus d'un an. C'est Alisdair Meredith qui l'a remplacé. Mais il en reste un membre actif.

A noter, comme "gros" changement cette semaine : new et explicit ne sont plus utilisés pour la gestion de l'overload (par contre, final et override restent en place). L'utilisation de noexcept dans la bibliothèque a été rationalisée (et un grand nombre de spécifications ont été enlevées). Les règles de recherche de begin et end pour un range-for ont été modifiées : Le compilateur les cherchera en premier lieu sous la forme de fonctions membre, et s'il ne les trouve pas sous la forme de fonctions libres. Ce qui évitera entre autre une ambiguïté avec boost.

**Klaim** · 26/03/2011, 01h11

new et explicit ne sont plus utilisés pour la gestion de l'overload

Tu peux préciser? Je ne vois pas du tout de quelle feature tu parles?

Sinon, j'ai entendu dire que les custom string-literal étaient remis en question. Finalement ils sont bien dans C++0x?

Enfin au niveau du nom, finalement ça sera C++11 ou C++2011?

**JolyLoic** · 26/03/2011, 01h30

Certains voulaient retirer les user defined literals, ainsi que le forwarding des constructeurs de la classe de base. Rien n'a finalement été retiré.

L'idée d'override, c'est de déclarer d'une fonction en redéfini bien une autre. Si on ne trouve pas de fonction virtuelle correspondante dans la classe de base, il y a une erreur de compilation (exemple vécu : On ajoute const dans un argument de la fonction virtuelle de la classe de base, tout compile, rien ne marche. Là, on aura une elle erreur en compilant la classe dérivée).

A partir de là, le reste me semble plus optionnel. Final indique que l'on ne va pas dériver plus.

Explicit (à mettre à côté du nom de la classe) avait pour but de forcer une classe à déclarer override (et pas seulement virtual) les fonctions qui redéfinissaient une fonction de la classe de base. Et dans ce contexte, new avait pour but de déclarer une fonction avec le même nom qu'une fonction de la classe de base, mais ne la redéfinissant pas. Il y avait des difficultés sur l'utilisation de new, et sans new, ou avec un new partiel (par exemple, sur les fonctions mais pas sur les données membre ni les types) des questions se posaient sur explicit, et les problèmes de compatibilités qu'il pourrait causer. Du coup les deux ont été enlevés.

Pour le nom, j'espère fortement que ce sera C++11, mais ça dépend aussi de la vélocité de l'ISO.

**Klaim** · 26/03/2011, 11h04

Ok merci pour l'explication, je savais pas pour new et explicit.

Herb Sutter commence a faire echo : http://herbsutter.com/2011/03/25/we-...ndards-meeting

If all goes well, and we expect it will, the International Standard will be approved and published in 2011, henceforth to be known as C++ 2011.

Donc ça serait C++2011? Perso ça me va.

**Goten** · 26/03/2011, 11h32

Envoyé par JolyLoic

Zut tu m'as grillé, je voulais faire l'annonce en quasi direct, je n'aurais pas du aller fêter ça au resto avec les autres...

On a effectivement voté pour que la version du draft après les modifications de cette semaine soit proposée comme la nouvelle version du C++. Ça peut prendre un temps indéterminé à finaliser, mais on (Herb, en particulier) tente de faire ce qu'on peut pour accélérer la partie administrative.

Ps : Howard n'est plus en charge du library working group depuis un peu plus d'un an. C'est Alisdair Meredith qui l'a remplacé. Mais il en reste un membre actif.

A noter, comme "gros" changement cette semaine : new et explicit ne sont plus utilisés pour la gestion de l'overload (par contre, final et override restent en place). L'utilisation de noexcept dans la bibliothèque a été rationalisée (et un grand nombre de spécifications ont été enlevées). Les règles de recherche de begin et end pour un range-for ont été modifiées : Le compilateur les cherchera en premier lieu sous la forme de fonctions membre, et s'il ne les trouve pas sous la forme de fonctions libres. Ce qui évitera entre autre une ambiguïté avec boost.

Comme gros changement y'a aussi "decltype", à l'heure actuelle toute les implémentations sont devenues défectueuses et fausses. Et c'est très bien car decltype avait plusieurs soucis, qui ont été résolu.

sinon.... ben HOUURAY `\o/