[futur] L'après C++11

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 ! :mrgreen:

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. :D
Et vous ? Quels sont les features ou lib que vous souhaiteriez absolument avoir pour C++1x ( C++2x ) ?

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.

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 :)

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).

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?

Citation:

---

Envoyé par Freem

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.

Citation:

---

Envoyé par oodini

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 8O 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 :roll:

Citation:

---

Envoyé par Freem

[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

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.

Citation:

---

Envoyé par Freem

Il a l'air intéressant sur le papier (si j'ose dire) mais... Il date de l'an 2000 8O 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...

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.

Pour ma part, je ne demande pas grand chose, si le comité pouvait sortir une release intermédiaire contenant uniquement filesystem et module, alors je serais parfaitement heureux. :D

Du coup ça m'attriste de lire :

Citation:

---

Envoyé par JolyLoic

(mais à priori, vue la volonté de réduire le temps entre deux version, [les modules] ne seront probablement pas dans le prochain standard, peut-être le suivant).

---

Pas le prochain mais le suivant... il faut tabler sur quoi 10 ans ? 15 ans ?

Citation:

---

Envoyé par Emmanuel Deloget

"Modules in C++", qui devrait - à terme - permettre l'écriture de modules largement indépendant des autres

---

Pour info, de ce que j'ai pu voir des commits récents sur clang, Douglas Gregor travaille à toute vapeur depuis environ deux mois pour implémenter les modules dans clang. Et vu que c'est un génie doublé d'un bourreau de travail on devrait pouvoir commencer à tester les modules d'ici peu. :mrgreen:

Les date (en fait la gestion du temps en standard serais pas mal, coté boost on a chrono qui a reussi a faire quelque chose de pratique).
L'unicode, parce que de toute façon c'est l'avenir.
Le static_if (sucre syntaxique certe), qui permet de faire un jolie chose avec constexp.
Les concept pour debug facilement la metaprog.
J'aimerais bien voir des implémentation standard de pool et d'allocator (je pense a boost object_pool et pool_allocator), c'est quelque chose qui est absolument nécessaire pour faire du code propre et pourtant il n'y a rien dans la stl.

*prie pour que les modules arrivent rapidement*

J'ai dit aussi concepts parceque visiblement ça peut aussi aider à réduire les temps de compilation si on utilise bien les axiomes.

Sinon je viens de parcourir la proposition du Rich pointer, effectivement c'est ... osé. Ce que je ne comprends pas c'est pourquoi c'est un pointeur et pas par exemple une décoration de déclaration de classe

Code:

---

reflect class MaClass { ...}

---

Mais bon j'ai pas encore tout lu...

Pour ma part, ça sera deux choses sur les templates :
template <typename T> :aie:

• Conversion implicite entre T et const T. Mais cette feature doit plus dépendre des compilateurs. Qui ne s'est jamais arraché les cheveux dessus ?
• Dans le cas où T est une classe, pouvoir apporter des informations sur T comme en Java avec des trucs du style <T : public UneClasse> pour dire que la classe "UneClasse" hérite de la classse template ou <UneClasse : public T> si c'est le paramètre template qui hérite de "UneClasse".

Citation:

---

Envoyé par JolyLoic

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.


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.

---

Le souci de la STL, c'est que, dans une certaine mesure, on ne peut pas vraiment séparer l'implémentation du template lui-même je dirai. Ou dans une faible mesure seulement...

(Je ne cherche pas juste à contredire, juste à comprendre ce que vous entendez par modules... J'ai l'impression de rater un train la xD)

@air-dex:
Plutôt le contraire non? :P
Sinon, je pense que tu peux déjà vérifier à la compilation qu'un paramètre template hérite d'une classe en utilisant typeinfo et quelques directives de précomp pour éviter de polluer le code release... Ca resterai du bricolage par contre, et je suis même pas sûr que ça marche puisque jamais essayé... (je tenterai ce soir tiens c'est une bonne question)

Citation:

---

Envoyé par Arzar

Pas le prochain mais le suivant... il faut tabler sur quoi 10 ans ? 15 ans ?

---

Pour le moment il n'y a pas de plan, juste des idees de plan plus ou moins bien formulees.

Citation:

---

Pour info, de ce que j'ai pu voir des commits récents sur clang, Douglas Gregor travaille à toute vapeur depuis environ deux mois pour implémenter les modules dans clang. Et vu que c'est un génie doublé d'un bourreau de travail on devrait pouvoir commencer à tester les modules d'ici peu. :mrgreen:

---

J'espere que ca ne va pas finir comme les concepts.

Citation:

---

Envoyé par Freem

(Je ne cherche pas juste à contredire, juste à comprendre ce que vous entendez par modules... J'ai l'impression de rater un train la xD)

---

La proposition de David VdV (je n'ai aucune idee de ce que DG fait) est une notion purement front-end. En gros des .h automatiquement generes et dont l'inclusion aurait un effet garanti independant de ce qui a ete inclu avant. Oui, on pourrait y mettre les definitions des templates sans problemes (et en tout cas sans une serie de problemes qu'export avait a regler, David VdV etant celui qui a implemente export, il les connait bien).

Bon j'ai fini de lire la nouvelle version de la proposition des Modules.

C'est plus clair que la précédente, mais j'ai deux remarques :

1. La syntaxe proposée pour les fichiers interface me semble inutilement difficile à lire. Je ne comprends pas bien pourquoi il faut que les noms aient des numéros pour les rendre uniques, ils ne sont pas censés être uniques de toutes façon? Le module est répété dans le fichier donc je ne vois pas pourquoi c'est nécessaire.

2. Je préférerai de loin qu'un module ne compile pas si on a une fonction publique qui retourne un objet d'un type privé plutot que de rendre ce type publique. De cette manière celui qui implémente le module doit savoir et définir clairement ce qui est publique et ce qui ne l'est pas. Si il déclare une fonction qui retourne un type privé, il doit être notifié de ce qu'il fait, et pas juste avec un warning... :aie:

Sinon vivement qu'on ai les modules! :ccool:

Citation:

---

Envoyé par Klaim

1. La syntaxe proposée pour les fichiers interface me semble inutilement difficile à lire. Je ne comprends pas bien pourquoi il faut que les noms aient des numéros pour les rendre uniques, ils ne sont pas censés être uniques de toutes façon? Le module est répété dans le fichier donc je ne vois pas pourquoi c'est nécessaire.

---

Le fichier interface est généré à partir du module, et a pour consommateurs prévus les compilateurs qui compilent qqch important le module et des outils divers. L'ajout de numéro permets à ces derniers de pouvoir faire qqch sans devoir implémenter la résolution des noms.

Citation:

---

2. Je préférerai de loin qu'un module ne compile pas si on a une fonction publique qui retourne un objet d'un type privé plutot que de rendre ce type publique. De cette manière celui qui implémente le module doit savoir et définir clairement ce qui est publique et ce qui ne l'est pas. Si il déclare une fonction qui retourne un type privé, il doit être notifié de ce qu'il fait, et pas juste avec un warning... :aie:

---

Ça ne change pas du comportement qu'on a actuellement avec des classes imbriquées privées.

Citation:

---

Envoyé par Jean-Marc.Bourguet

Le fichier interface est généré à partir du module, et a pour consommateurs prévus les compilateurs qui compilent qqch important le module et des outils divers. L'ajout de numéro permets à ces derniers de pouvoir faire qqch sans devoir implémenter la résolution des noms.

---

Donc, que se passe-t-il pour l'utilisateur d'une bibliothèque, qui n'a qu'un fichier d'interface et un binaire, et qui n'a pas accès à un IDE? (comme moi dans mon boulot actuel)

Pour connaitre l'interface (du code) il doit soit lire le fichier un peu cryptique d'interface qu'il a, soit lire une doc externe (qui n'est pas forcément fournie).

Soit avoir des headers...


Donc, si le fichier d'interface pouvait être lisible directement, ça serait plus pratique...

...et je vois pas bien le problème avec le compilateur, il va de toutes façon faire une représentation intermédiaire optimizée séparée de ce fichier...

Citation:

---

Ça ne change pas du comportement qu'on a actuellement avec des classes imbriquées privées.

---

Oui mais ça change du comportement des types non définis retournés par des fonctions. Là tout ce qui est privé est censé être non-définis, donc une erreur dans ce genre de cas éviterai beaucoup de potentielles "fuites d'accès"...

Si filesystem et date pouvaient être présents, ce serait déjà bien. La STL ressemblerait enfin à quelque chose ; on pourrait enfin croiser un dev Java sans baisser les yeux.

Citation:

---

Envoyé par air-dex

---

Tout ça doit bien pouvoir se résoudre avec les type_traits de C++11, non ?
std::remove_const<T> pour le premier point et std::is_base_of<B,D> pour le reste ?