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)
Version imprimable
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)
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 ! :)
Vous savez si cette nouvelle norme offrira un mécanisme similaire à final en Java ou sealed en C# ?
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 :mrgreen:
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.Citation:
Envoyé par Arzar
(Et si j'ai bien suivit, ca sera encore modifie).
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++...
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 :
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:
2
3
4
5
6
7
8
9
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...Code:
2
3
4
Avec override, à la recompilation, le responsable de la classe B aurait eu une erreur, et le problème aurait été corrigé immédiatement.
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.
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).Citation:
Envoyé par JolyLoic
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 :)Citation:
Envoyé par oodini
Existe-t-il une liste (ou mieux, une matrice) des bibliothèques Boost qui ont été incluses dans cette nouvelle norme ?
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.
THIS IS IT !!
Howard Hinnant, le président du Library Working Group du comité C++ vient de lâcher le morceau sur Stack Overflow !!
:lahola: Le draft final est terminé !! :lahola:
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 !
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.
Tu peux préciser? Je ne vois pas du tout de quelle feature tu parles?Citation:
new et explicit ne sont plus utilisés pour la gestion de l'overload
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?
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.
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
Donc ça serait C++2011? Perso ça me va.Citation:
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.
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.Citation:
Envoyé par JolyLoic
sinon.... ben HOUURAY `\o/
O__O;
C'est quoi les changements avec decltype? Parceque je l'utilise pas mal dans mes projets...
Le problème est avec le protocol result_of.
http://www.open-std.org/jtc1/sc22/wg...011/n3233.html
Toute l'histoire :). (ça a été accepté bien entendu)
Le comité ISO C++ valide le Draft final de la norme C++ 0X
il sera publié officiellement dans les mois avenir
Mise à jour du 29/03/11, par Hinault Romaric
Les travaux pour la définition de la nouvelle norme pour le langage de programmation C++ sont enfin achevés et validés.
La norme, qui remplacera celle de 1997, et dont la publication initiale était prévue au plus tard pour 2010, vient de franchir un cap majeur. Le comité de normalisation ISO C ++ vient en effet d'approuver les dernières modifications techniques lors d'une réunion qui s'est tenue du 21 au 25 mars à Madrid en Espagne, sur le Draft final (Final Commitee Draft) et sur un Draft international (Final Draft International Standard - FDIS).
Pour Herb Sutter, président du comité ISO C++, le FDIS est de «très bonne qualité », ce qui en quelque sorte pourrait justifier le retard accusé dans sa validation. « Nous avons pris beaucoup plus de temps pour produire la seconde norme du C++. C'est en partie à cause de ses fonctionnalités ambitieuses, et surtout sa qualité [...] Cette norme est largement considéré comme le document FDIS de plus haute qualité que nous n'ayons jamais élaboré » écrit-il sur son blog.
Au menu, des changements comme l'abandon des clauses new et explicit pour la gestion des overload, la rationalisation de l'utilisation de noexcept dans la bibliothèque ou la modification des règles de recherche de Begin et end pour un range-for.
On notera également la suppression de plusieurs spécifications jugées obsolètes.
La publication officielle de la norme est prévue pour cette année, si le FDIS est validé lors d'une ultime réunion à Genève.
Le nouveau standard aura finalement pour nom de code C++ 2011., mettant ainsi fin à toutes les spéculations. Et à toutes les plaisanteries.
Source : Blog Herb Sutter
Et vous ?
:fleche: Que pensez-vous de cette nouvelle norme?
Aprés Duke Nukem forever, C++ 2011.
Vraiment une sale année pour les trolls 2011 :mrgreen:
Que du bon, vivement une implémentation à 100% dans GCC, j'en salive déja sur mon clavier
"si le FDIS est validé lors d'une ultime réunion à Genève"
Tout n'est donc pas encore validé, je suis un peu perdu avec cette phrase ... ?
Il manque une étape administrative, donc officiellement il sera "finis" vers juillet. Mais techniquement il est déjà fini.
Un peu comme quand tu finis un jeu vidéo mais que l'editeur a besoin de faire un travail marketing autour avant de le mettre dans les bacs.
...
Sauf que c'est pas du marketing, mais juste de l'administration ISO.
Enfin vous m'avez compris quoi. :aie:
Au fait, ce nouveau standard ne permet toujours pas de faire:
:question:Code:std::vector< MaClasseTemplate< UnType > >
Parce que les variadic templates m'ont induit en erreur, et je suis un peu perdu :oops:
Sinon, visual 2010 implémente pas encore final et override :cry:
Comment cela?Citation:
Envoyé par r0d
tu peux même le faire en c++98 ça..Citation:
Envoyé par r0d
En même temps ils ont été "fixés" il y a très peu de temps hein...Citation:
Sinon, visual 2010 implémente pas encore final et override
En même temps, je suis dubitatif sur leur intérêt. A priori, j'ai l'impression qu'une utilisation de NVI réduit pas mal les cas 'utiles' de override. Quand à final, à part à des fins d'optimisations par le compilateur, j'avoue que j'en vois mal l'intérêt.Citation:
Envoyé par Klaim
Je ne vois pas trop le lien entre override et NVI. Il y a quand même pas mal de cas où, même avec NVI, la classe de base peut définir une implémentation pour la fonction virtuelle. Et dans ce cas, il est intéressant pour la personne écrivant une classe dérivée de pouvoir être certaine qu'elle ne s'est pas plantée dans l'écriture d'une fonction remplaçant cette fonction virtuelle non pure (ou que la définition de la fonction virtuelle non pure dans la classe de base n'a pas été modifiée par la suite).Citation:
Envoyé par 3DArchi
Effectivement ma mémoire m'a joué des tours. J'avais retenu que l'idée derrière était d'éviter les masquages de fonctions (qui sont empêchés par NVI) alors qu'il y a aussi la conformité de la signature (qui n'est vérifiée ... qu'au plantage de l'exécution sinon :aie:). Je n'ai pas encore lu la dernière mouture du draft (le n342 il me semble) mais cela s'appliquerait plus à new pour les 3 lignes que j'ai pris le temps de voir.Citation:
Envoyé par JolyLoic
Ceci étant dit, je suis toujours interrogatif sur final.
Je n'arrive pas à trouver de reference sur ce "final" qui me semble pas trés logique.Citation:
Ceci étant dit, je suis toujours interrogatif sur final.
Où as-tu vu que "final" allait être implémenté dans le draft ?
C'était l'un des attributs qui sont passé en mots-clés récemment.
Personellement je pense que, utilisé avec beaucoup de parcimonie, ça peut être utile, notemment pour les conteneurs de la stl que certains débutants ont tendance a prendre comme base d'autres classes... le souci c'est surtout que rien ne te dit (sauf warning de certains compilateurs) que tu ne devrais pas hériter d'une classe sous pretexte que tupeux, au risque d'avoir des problèmes obscures au runtime (parceque le destructeur de la classe de base n'est pas virtuel.
Là ce serait un moyen de dire explicitement : non.
Mais il est facile d'abuser de ce genre de feature.
Dans l'ancienne version que j'avais (la n3126) c'était dans les attributs : 7.6.4 Final attributeCitation:
Envoyé par Firwen
Mais dans la nouvelle version (n3242) (pas encore regardée pour ma part), si j'ai bien compris final/override sont passés en mots clés. Tu les as dans 9 Classes (class-virt-specifier) et dans 9.2 Class member (virt-specifier)
C'est omettre que l'héritage privé peut avoir de l'intérêt à la place de l'encapsulationCitation:
Envoyé par Klaim
Sans compter que les inheriting constructors permet de plus facilement hériter d'une classe non prévue pour dans les cas où ça a du sens (adapter).
Concernant les templates, en fait je me suis mal exprimé, je voulais parler de vecteur (ou n'importe quel conteneur template) contenant une classe template non spécialisée. Par exemple:
Je ne sais pas pourquoi, j'avais compris que les variadic templates servaient à résoudre ce problème. Sans doute est-ce mon anglais (approximatif) qui m'a joué un tour.Code:
2
3
4
5
6
7
8
Ça peut paraître bizarre de souhaiter pouvoir faire cela, car à première vue ça n'a pas vraiment de sens. Mais en fait je crois que ça pourrait être utile. J'étais tombé sur ce "besoin" quand j'avais tenté de faire une machine à état finie générique. En effet, je voulais créer un tableau de transitions, les transitions étant des templates dont les types sont les 2 états (départ, arrivée). [HS] C'est d'ailleurs un problème intéressant cette histoire de machine à état, et j'ai toujours pas trouvé de solution générique et élégante. [/HS]
Mais alors du coup, les variadic template ça rend obsolète les typelist? (comme vous le voyez, les templates c'est pas mon truc :aie: )
OuiCitation:
Envoyé par r0d
non. Ca rend l'écriture un peu moins absconse
Y'a les template typedef.Citation:
Envoyé par r0d
Non.Citation:
[/HS]
Mais alors du coup, les variadic template ça rend obsolète les typelist? (comme vous le voyez, les templates c'est pas mon truc :aie: )
@guillaume : les typelists c'est pas destiné uniquement à émuler les variadic templates ... (et pire ont a de meilleure méthode pour le faire).