IdentifiantMot de passe
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

L'après C++11 : quels sont les features ou lib que vous souhaiteriez dans la future norme ?
Le premier document des propositions publié

Le , par Arzar
41 commentaires

47PARTAGES

8  0 
L'après C++11 : Quels sont les features ou lib que vous souhaiteriez dans la future norme ?
le premier document des propositions publié

Le comité C++ vient de publier son premier mailing post-C++11 !

Du coup, on sent bien que tous les features et lib qui avaient été mis de coté depuis quelques années pour se concentrer sur le C++11 refont surface et on a droit à une déferlante de papier tous plus foufou les uns que les autres !

En vrac :

concepts, module, filesystem, range, date, coroutine, mémoire transactionnelle, string_ref, Fixed-point arithmetic, digit seperator, concurrent queue, stream mutex !

Et pour le spectaculaire :
static_if : W. Bright (Concepteur du D) et A. Alexandrescu (grand promoteur du D) reviennent faire un tour en terre cplusplussienne et nous proposent une construction issue du D !!
Rich_pointer : Permet de l'introspection/reflection au runtime via un smart pointer étrange.

Bon, je suppose que les 3/4 de ces propositions n'auront aucune chance de finir dans le standard, mais ce petit vent de folie sur la planète C++ est assez plaisant.
Et vous ? Quels sont les features ou lib que vous souhaiteriez absolument avoir pour C++1x ( C++2x ) ?
Vous avez lu gratuitement 10 articles depuis plus d'un an.
Soutenez le club developpez.com en souscrivant un abonnement pour que nous puissions continuer à vous proposer des publications.

Une erreur dans cette actualité ? Signalez-nous-la !

41 commentaires
Commenter Signaler un problème
Emmanuel Deloget
Avatar de Emmanuel Deloget
Expert confirmé https://www.developpez.com
Le 23/01/2012 à 23:03
Le proposal qui me parait le plus intéressant, ce sont les resumable functions. Elles devraient aider à écrire du code async de manière relativement simple. Dans un registre similaire, la proposition qui permettrait l'écriture de code transactionnel pourrait, elle aussi, simplifier très nettement l'écriture de code concurrent - on sait tous que le code consurrent est difficile à écrire et encore plus difficile à maintenir.

Un autre proposal digne d'intérêt selon moi, c'est le "Modules in C++", qui devrait - à terme - permettre l'écriture de modules largement indépendant des autres, et donc limiter très nettement les temps de compilation (imaginez que les headers de la C++SL soient accessibles via un module déjà pré-compilé. Le rêve, non ?)

L'essai sur les implémentations possibles d'une classe std::date est aussi très largement intéressant (au niveau lecture). Au niveau de la solution préconisée, j'ai l'impression qu'il manque une certaine finesse. Personnellement, ma classe date serait un template prenant en types paramètres un date_storage, un date_storage_traits et un calendar_traits (au moins). Le papier tente trop (à mon goût) de forcer une implémentation spécifique (l'idée, par exemple, de forcer l'utilisation d'un calendrier grégorien proleptique est à mon sens une mauvaise idée. D'abord parce que mes objets std::date, je voudrais pouvoir les transformer en une autre représentation (calendrier julien, grégorien (invalide avant son instauration, ou dérivant sur le julien si nécessaire), voire chinois (puisque c'est le moment) ou musulman), ensuite parce que la culture de mon pays n'est pas nécessairement très occidentale, et que j'en ai peut-être pas grand chose à faire de ce calendrier grégorien proleptique).

N3336 (Adapting Standard Library Strings and I/O to a Unicode World) est quelque chose qui me tiens à coeur. Aujourd'hui, devoir écrire ses propres routines de traitement/conversion des chaines unicode est quelque chose qui me dépasse un peu. Même remarque sur N3335 (Filesystem Library for C++11/TR2 (Revision 1)) ; ces deux proposals tentent de limiter les difficultés dans deux domaines importants : le portage et l'internationalisation.

Enfin, le retour des concepts ne peut être qu'une bonne chose
3  0 
Flob90
Avatar de Flob90
En attente de confirmation mail https://www.developpez.com
Le 23/01/2012 à 18:10
Pour les avoir testé avec boost, le concept de range serait vraiment une bonne chose à intégrer à la STL, à première vue ca ressemble juste à une paire d'itérateur, mais à l'utilisation c'est vraiment plaisant.

string_ref/array_ref, j'ai regardé en diagonale le papier, ca à l'air sympa, mais j'y crois pas trop pour être dans le prochain standard. Et l'idée des rich pointer me semble vraiment farfelus (c'est un ajout à la syntaxe du langague qui me semble un peu surfait).

static_if est surment une bonne idée, même si sur le fond ce n'est (à première vue, il y a peut-être des subtilités que je n'ai pas vu) que du sucre syntaxique. Mais si la complexité de mise en place est faible et que ca ne coûte pas grand chose niveau perf, ca peut être un ajout ayant quelques utilités.

Il y a aussi un papier concernant l'adaptation de la STL (IO/string) pour la gestion Unicode qui serait intéressant, comme filesystem et date.
1  0 
Klaim
Avatar de Klaim
Membre expert https://www.developpez.com
Le 26/01/2012 à 15:18
Je viens de lire la courte proposition des scoped new. http://www.open-std.org/jtc1/sc22/wg...2012/n3348.pdf
Je crois qu'ils se sont raté sur les exemples, ils n'ont pas mis de namespace...

Pouvoir définir un new à utiliser par namespace ça serait le top (même si ça pourrait en embrouiller) surtout pour les bibliothèques.
1  0 
JolyLoic
Avatar de JolyLoic
Rédacteur/Modérateur https://www.developpez.com
Le 24/01/2012 à 2:14
Pour moi, modules, modules et modules ! (mais à priori, vue la volonté de réduire le temps entre deux version, ça ne sera probablement dans le prochain standard, peut-être le suivant).

Ensuite, concepts puis systèmes facilitant la métaprogrammation (je ne suis pas encore fixé sur ce que je pense des différentes propositions dans ce sens).
0  0 
Freem
Avatar de Freem
Membre émérite https://www.developpez.com
Le 24/01/2012 à 11:12
Je n'ai pas (encore) lu ces papiers, en tout cas, une chose me paraît assez évidente: presque tous les programmes manipulent des fichiers. Donc filesystem serait vraiment une grande aide.

Pareil, la manipulation de date est très commune, et très infernale en C++. En fait, aussi infernale qu'en C, puisqu'il n'y a pas (a ma connaissance) de différences :'(
J'aimerai qu'un jour, il n'y ait plus besoin d'apprendre une API différente de gestion des dates/heures à chaque fois que l'on tape dans un SGBD différent, notamment.

Dernière chose, l'unicode, universellement encensé, est effectivement une faiblesse du C++. Je crois qu'il y a déjà les w_char & co, mais j'admets ne pas savoir comment tout ça marche. (en fait, je devrais plutôt admettre ne pas connaître grand choses des fonctionnalités avancées du C++, il faudrait vraiment que je trouve une sorte de "cheatsheet" à ce sujet un jour, qui les décrive brièvement... Ca me serait d'une grande aide pour améliorer ma connaissance de ce langage!)

Ce sont surtout des modifications qui impacteraient la bibliothèque, mais qui manquent cruellement, à mon humble avis.
Ce sont aussi des modifications qui amélioreraient l'une des forces du C++: la portabilité de ce langage. (L'internationalisation est, somme toute, une forme de portabilité)

Static_if, dis comme ça, je vois pas? Un if vérifié à la compilation? Comme #if non?
Mais c'est sûr que le système de précompilation gagnerait à être enrichi, les templates pourraient gagner en puissance encore plus si on pouvait générer du code vraiment dynamiquement à la compilation.

Les autres trucs, de base, je vois pas trop à quoi ça se rapporte, faudra que j'aille lire les papiers...

[edit]
Et pour la C++SL, il y a au moins la STL qui ne pourra pas rejoindre les modules, si je comprend pas tout de travers, vu que l'implémentation est générée à la compilation
Et la STL est une grosse part de la SL j'ai l'impression...

Et il y à une volonté de réduire le temps entre deux standards? Ce serait une excellente chose. Quelqu'un a un lien à lire à ce sujet, svp?
0  0 
oodini
Avatar de oodini
Membre émérite https://www.developpez.com
Le 24/01/2012 à 11:26
Citation Envoyé par Freem Voir le message
Dernière chose, l'unicode, universellement encensé, est effectivement une faiblesse du C++. Je crois qu'il y a déjà les w_char & co, mais j'admets ne pas savoir comment tout ça marche. (en fait, je devrais plutôt admettre ne pas connaître grand choses des fonctionnalités avancées du C++, il faudrait vraiment que je trouve une sorte de "cheatsheet" à ce sujet un jour, qui les décrive brièvement... Ca me serait d'une grande aide pour améliorer ma connaissance de ce langage!)
Il y a semble-t-il une référence sur ces sujets, mais je en connais pas ce bouquin.
0  0 
Freem
Avatar de Freem
Membre émérite https://www.developpez.com
Le 24/01/2012 à 11:34
Citation Envoyé par oodini Voir le message
Il y a semble-t-il une référence sur ces sujets, mais je en connais pas ce bouquin.
Il a l'air intéressant sur le papier (si j'ose dire) mais... Il date de l'an 2000 je ne savais même pas programmer à cette époque xD
Pour le coup, il a 2 standards C++ de retard, si je ne me plante pas: 2003 et 2011... (bon, il semble que 2003 soit une 'simple' correction de 1999, mais quand même, C++ et ses pratiques ont dû évoluer depuis j'espère?)

Et mon commentaire sur la "cheatsheet" concerne en fait le C++ de manière générale. J'ai bien l'impression que ma connaissance des possibilités de ce langage est quasi-nulle, alors qu'il s'agit de mon langage préféré et sûrement celui que je connaît le mieux! Pour le coup j'ai un peu honte quand même... Mais je me dis que c'est peut-être l'un des plus complets en terme de possibilités, histoire de pas trop pourrir mon égo
0  0 
JolyLoic
Avatar de JolyLoic
Rédacteur/Modérateur https://www.developpez.com
Le 24/01/2012 à 11:40
Citation Envoyé par Freem Voir le message

[edit]
Et pour la C++SL, il y a au moins la STL qui ne pourra pas rejoindre les modules, si je comprend pas tout de travers, vu que l'implémentation est générée à la compilation
Et la STL est une grosse part de la SL j'ai l'impression...
Les modules n'empêcheraient pas les templates, le but n'est pas de mimer les bibliothèques dynamiques (mêmes s'ils peuvent servir de base pour des bibliothèques dynamiques), mais plus de modifier la chaîne de compilation pour avoir quelques frontières bien isolées qui permettent de raisonner sur des bouts de code sans être pollués par d'autres bouts, et donc d'assembler un programme de manière plus simple. Accessoirement, mais c'est un accessoire crucial, cette séparation permettrait de pré-compiler plein de choses, et donc d'accélérer drastiquement le temps de compilation.

Citation Envoyé par Freem Voir le message
Et il y à une volonté de réduire le temps entre deux standards? Ce serait une excellente chose. Quelqu'un a un lien à lire à ce sujet, svp?
Pas de lien, non, juste des mails sur les mailing lists du comité. Mais ce sera assurément discuté lors de cette réunion. Le consensus actuel semble être autour de quelques modifications simples pour la prochaine version, et en parallèle on commence à travailler sur celle d'après, de manière à pouvoir y introduire des modification de plus grosse envergure.
0  0 
oodini
Avatar de oodini
Membre émérite https://www.developpez.com
Le 24/01/2012 à 11:54
Citation Envoyé par Freem Voir le message
Il a l'air intéressant sur le papier (si j'ose dire) mais... Il date de l'an 2000 je ne savais même pas programmer à cette époque xD
Pour le coup, il a 2 standards C++ de retard, si je ne me plante pas: 2003 et 2011... (bon, il semble que 2003 soit une 'simple' correction de 1999, mais quand même, C++ et ses pratiques ont dû évoluer depuis j'espère?):
Le bouquin de référence sur la STL date de 1999 (même s'il y a eu quelques mises à jour depuis,), celui sur les templates de 2002, celui d'Alexandrescu de 2001...
0  0 
Klaim
Avatar de Klaim
Membre expert https://www.developpez.com
Le 24/01/2012 à 13:40
Si ils pouvaient se concentrer sur les modules et les concepts et faire une version rapidement, ça serait mieu que de les repousser... mais bon ya plein de paramettres en jeux aussi.
0  0 
Commenter Signaler un problème