[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 :)
--
Benoit Sigoure aka Tsuna
Software Engineer Intern (Ads SRE)
Office Location: US-MTV-42 177D
Office Phone: +1 (650) 214-0335
--
Benoit Sigoure aka Tsuna
Software Engineer Intern (Ads SRE)
Office Location: US-MTV-42 177D
Office Phone: +1 (650) 214-0335
[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 :)
--
Benoit Sigoure aka Tsuna
Software Engineer Intern (Ads SRE)
Office Location: US-MTV-42 177D
Office Phone: +1 (650) 214-0335
