Discussion :

[Klaim]

Le comité ISO C++ valide le Draft final de la norme C++ 0X
Son nom sera C++ 2011

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ée 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 ?

Que pensez-vous de cette nouvelle norme?


Herb Sutter nous fait part sur son blog de la conclusion du dernier vote du comité qui s'est déroulé à Pittsburgh.


La principale bonne nouvelle est que le Final Commitee Draft a été voté et ne sera donc changé que pour des corrections de bugs et autres typos. Autrement dit, il ne reste qu'a faire valider le draft par ISO et nous auront enfin la nouvelle norme fixée.

D'après Herb, le temps que cela se passe, nous serons en 2011.

Parmi les derniers changements, la suppression définitive d'export template mais surtout la déprécation des spécifications d'exception et l'ajout d'un qualificateur : noexcept.
A priori ça sera bien plus intéressant que les spécification d'exceptions.

[Goten]

Bonne nouvelle. Et bonne nouvelle de s'être débarrassé des spécifications d'exceptions... Ça évitera du smell code

[3DArchi]

Il propose même un nom C++11 pour que les moqueries autour du x c'est pour l'hexa dans C++0x s'arrêtent
Plus sérieusement, c'est une bonne nouvelle. Si la norme est stabilisée, les compilateurs vont pouvoir se mettre au diapason et nous allons pouvoir utiliser ces nouvelles possibilités. YAPUKA les assimiler
Le draft voté est le 3035 ? Si non, il y a moyen d'avoir le draft voté ?

[Jean-Marc.Bourguet]

Il propose même un nom C++11 pour que les moqueries autour du x c'est pour l'hexa dans C++0x s'arrêtent
Plus sérieusement, c'est une bonne nouvelle. Si la norme est stabilisée, les compilateurs vont pouvoir se mettre au diapason et nous allons pouvoir utiliser ces nouvelles possibilités. YAPUKA les assimiler
Le draft voté est le 3035 ? Si non, il y a moyen d'avoir le draft voté ?

Dans le prochain mailing. Ce qui a été voté comme c'est N3035 + une série de modifications.

[ash.ice.loky]

Ouha impressionné par ce langage next-gen qui aura mi moins d'un an pour trouver un nom

[koala01]

Salut,

Ouha impressionné par ce langage next-gen qui aura mi moins d'un an pour trouver un nom

Si tu fais référence à C++11, il faut savoir qu'il a changé pas mal de fois, entre C++0x jusqu'à la fin de l'année 2009, C++1x depuis peu, et maintenant C++11, qui devrait être le nom final

Il faut se rappeler que cette nouvelle norme est "dans l'air du temps" depuis...2005 environ

[3DArchi]

En tout cas, ça permet d'intégrer plus sereinement quelques nouveautés déjà implémentées par certains compilateurs. Certes, entre maintenant, son adoption et la diffusion importante de nouveaux compilateurs compatibles, il va encore se passer beaucoup de temps, mais c'est déjà un grand pas dans la stabilisation.

[spidermario]

Ajouter les expressions lambda, les closures et l'inférence des types au standard de ce langage ne lui fera pas de mal (encore qu'il faudra faire attention aux copies lors de la capture d'une variable dans une closure, mais Qt implémente le COW pour beaucoup de ses classes)

[Médinoc]

Ça ne risque pas de géner pour les bibliothèques dynamiques, ça, la suppression définitives des export templates?

Ou bien je me trompe sur ce que c'est, et il ne s'agit pas là des instanciations explicites?

[Jean-Marc.Bourguet]

Ça ne risque pas de géner pour les bibliothèques dynamiques, ça, la suppression définitives des export templates?

Ou bien je me trompe sur ce que c'est, et il ne s'agit pas là des instanciations explicites?

Tu te trompes. Les templates exportes permettent de couper des dependances, mais il faut toujours le code (ou qqch d'equivalent semantiquement) au plus tard(*) lors de l'edition de liens et l'interaction avec les bibliotheques dynamiques n'est en rien facilitee par rapport aux templates non exportes.

(*) Les templates exportes n'apportent reellement quelque chose qu'en combinaison avec un mecanisme d'instantiation itere (que peu de compilateurs fournissent aussi, je me demande si ce n'est pas un facteur important mais jamais avoue dans la mauvaise volonte faite pour les implementer).

[Médinoc]

Les instanciations explicites de template, elles, sont-elles normalisées?

Je me souviens que pour l'instant, chaque compilo a sa propre extension qui n'a pas toujours la même syntaxe...

[Jean-Marc.Bourguet]

Les instanciations explicites de template, elles, sont-elles normalisées?

Oui.

Code :

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

1
2
 
template class Foo<Param>;

Je me souviens que pour l'instant, chaque compilo a sa propre extension qui n'a pas toujours la même syntaxe...

Tu confonds peut-etre avec les templates extern, extension de g++ (au moins) qui est standardisee en C++0X.

[Médinoc]

Oui, c'est ça. Merci.

[Arzar]

Vous avez vu le post d'Herb Sutter sur comp.lang.c++.moderated ?
On sent une telle effervescence, ça fait plaisir à voir !

I didn't realize how much of a turning point this week would feel
like, at least for me personally. It was kind of like I felt rather
than heard a distant "click" somewhere of the pieces snapping
together: the committee agreeing that the feature list is now final;
the implementations of key features starting to be delivered into real
customers' hands; the availability of many features in multiple
shipping implementations this year -- including multiple shipping
implementations available by this summer of auto, for loops, move
semantics, lambdas, and more that I'm probably forgetting; and Bjarne
starting work in earnest on TC++PL 4e.

It also struck me this week that this feels a lot like the mid/late
1990s again -- a new standard is coming that is adding significant
features to the language, and actual compiler implementations still
vary. There's a lot of room again for teaching material about how to
learn the new features, how to know what's portable today and what's
not, how to write code in a future-proof way that's portable today and
will stay portable tomorrow but also be ready to take advantage of new
features, etc.

Hmm, maybe it's time...

La remarque sur les mid 90' sonne juste, j'ai l'impression que l'on ne rentrera réellement dans l'ère C++0x que lors de la sortie de Visual Studio 2012/2013, data à laquelle tous les compilateurs majeurs seront probablement 100% conforme au standard.

Entre-temps ça risque d'être assez marécageux

(Et je crains que l'absence de template variadique dans VS2010 sera une épine bien plus pénible pour les développeurs de bibliothèque portable que l'absence de spécialisation partielle a pu l'être pour VS6)

[Klaim]

Ben ça dépends si Microsoft prends un rythme semblable au développement de Windows : des versions plus raprochées qui sont plus proches de "grosses" mises à jour.
Je ne sais pas si c'est dans leur plans, mais quelque chose me dit que vu leur politique actuelle sur les développements, il se peut fortement qu'on ai au moins des service pack avec d'autres features de C++0x--touss0Atousss-- C++11 au début de l'année prochaine...

Enfin j'espère XD

[Lightness1024]

avec tout ca et notamment les lambda fonctions je sens que les trucs genre intelli sense vont encore plus etre mis en defaut.
et déjà dans visual studio on pouvait rien watcher dans les namespace anonymes, qu'est-ce qu'on ne pourra plus débugger maintenant ??
avec C++ on pouvait se tirer dans le pied et ré-utiliser la balle, avec C++11 on pourra se tirer dans le pied, et perdre la jambe.

m'enfin vive les smart ptr dans le standard, vive la move semantic, vive les variadics (adieu 40 definitions de boost::bind, adieu script perl pour generer du code ""variadique"")...

[Klaim]

Les lambda marchent très bien avec Intellisense dans Visual Studio 2010 vu qu'ils ont tout revu pour Intellisense et que c'est sacrément plus efficace qu'avant.

J'ai jamais utilisé de namespace anonyme donc j'ai jamais remarqué de problème avec.

[Goten]

je m'inquiéte plus pour auto... Enfin non, pour des solutions comme VC, ils doivent utiliser le systéme d'inférence du compilo, mais pour des solutions comme code::blocks ça risque de devenir tricky.


Quand aux 40 définitions de boost::bind ça existera toujours, car avant que tout les compilos implémentent les variadics templates...

[Klaim]

C'est clair! Visiblement pour le nouvel Intellisense, les infos fournies quand tu pointe un auto sont bien précises.

[Arzar]

je m'inquiéte plus pour auto... Enfin non, pour des solutions comme VC, ils doivent utiliser le systéme d'inférence du compilo, mais pour des solutions comme code::blocks ça risque de devenir tricky.

Avec clang qui pointe le bout de son nez, je serais prêt à parier qu'on verra dans un futur pas trop lointain des améliorations drastiques chez les IDE coté open-source