[Je voulais mettre ça sur lrde.c++ mais il ne semble pas y avoir de ML associée]

Un mec qui bosse à Google et qui fait parti du commité de standardisation du C++ a fait un petit rapport sur ce qui s'est dit durant le meeting de juin. Je vous fait un résumé rapide (parce que je peux pas vraiment retransmettre le doc d'origine), la version officielle sera sur http://www.open-std.org/JTC1/SC22/WG21/ d'ici quelque temps (genre 1 ou 2 semaines).

La timeline actuelle: - Committee Draft en septembre - Final Committee Draft un an plus tard - le Standard un an encore après

Donc le standard devrait sortir en 2010, ou plutôt en 200A d'après certains :)

Concurrency

Beaucoup de travail de ce coté là, en particulier pour spécifier les intéractions mémoire entre les threads à un haut niveau d'abstraction. Il sera possible de déclarer des variables static (POD et non-POD) pour qu'elles soient locales à un thread. Ceci fait dorénavant parti du draft actuel. Le commité à aussi adopté des règles pour régir la construction et la destructions de variables static en présence de threads. Ceci soulevait des problèmes de backward compatibility, le commité semble avoir trouvé un compromis entre la proposition d'origine et une backward incompability complète. shared_ptr a des fonctionnalités en plus pour pouvoir être utilisé de manière atomique. Le commité à adopté une notion de thread-safety dans la bibliothèque standard. En gros, deux threads peuvent utiliser deux instances différente d'un type standard sans intérferer, et deux threads peuvent utiliser la même variable const de type standard sans intérferer. Le problème s'est posé au niveau de HP qui refuse ce changement pour basic_string car ça les forcerai à changer leur ABI. Le commité va essayer de faire passer ce changement quand même. Apparament y'a plus de détails sur les difficultés vis-a-vis de basic_string sur http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2534.html

Abstraction Mechanisms

Quelques modifs sur la définition de lambdas const. Beaucoup de modifs sur nullptr sans faire avancer le schmilblik. Apparament ils envisagent d'inclure des "user defined litterals", mais pour l'instant ça reste théorique car ça semble poser de sérieux problèmes de forward compatibility.

Templates

L'inclusion des concepts dans le standard se finalize, le vote final n'a pas pu avoir lieu car une partie du commité n'était pas prêt sur ce point. Les premiers changements dans la bibliothèque standard ont été fait et c'est OK de ce côté là. Le langage permet maintenant d'utiliser des types locaux et non-nommé en tant que template parameter. Le commité a eu quelques difficultés à préserver SFINAE par rapport à certaines extensions (non-type expressions as template arguments, decltype) mais ils font ce qu'ils peuvent pour préserver cet élément de meta-prog nécessaire.

Declarations

Une nouvelle syntaxe de déclaration des fonctions permet de déclarer le type de retour après la liste des arguments, ce qui permet entre autre d'avoir un type de retour dépendant du type des arguments, par exemple:

template< typename T, typename U > auto both( T t, U u ) -> decltype( t + u ) { .... }

Des discussions sont en cours pour unifier cette syntaxe avec celle des lambdas.

Garbage Collection

Ormis quelques parties qui insistent sur avoir des fonctionnalités de GC dans le C++, ça semble plutôt mort, bien que le commité semble avoir retenu 2 composants dans sa proposition. Le 1er empêche les programmeurs de faire des choses obscures avec les pointeurs sans se faire warninger la gueuler (eg. XOR'er des pointers, écrire/lire des pointers dans un fichier [?]). Le 2nd permet aux programmeurs de spécifier (en faisant appel à une API définie) des informations au GC tel que des zones mémoire sans pointeurs. Cette dernière proposition a été formellement incluse dans le draft.

Standard Library

La bibliothèque a grossi, principalement parce qu'ils essayent de mettre dedans tout ce qui peut s'implémenter raisonablement avec le langage actuel (plutôt que d'étendre le langage), ce qui est une bonne chose. Le namespace ::posix a été reservé pour le commité POSIX et ses futurs standards. Si du code existant utilise déjà ce namespace, il pourrait bien avoir besoin d'être changé. De nouveaux algos ont été ajoutés. Il est possible de faire des insertions en place dans certains conteneurs pour éviter d'avoir à recopier tout le contenu du conteneur. Dans le cadre de l'API pour les threads, le commité avait besoin de représenter le temps dans les mutex et conditions en ayant besoin. Ceci (date et temps) est donc désormais définis (dans une certaine mesure) dans le standard, et c'est basé sur la Boost Date Time Library (http://www.boost.org/doc/html/date_time.html). Les tableaux de tailles dynamiques (feature du C99) ont été proposé en tant que nouveau conteneur dans la bibliothèque standard, malheureusement cette proposition étant arrivé plutôt tard, elle n'a pas été retenue pour l'instant mais pourrait bien être adoptée peu après la sortie du standard.

Voilà, ça va en fait du boulot pour les transformers 2012 :)