Discussion :

[Arzar]

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

[Flob90]

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.

[Emmanuel Deloget]

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

[JolyLoic]

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

[Freem]

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?

[oodini]

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.

[JolyLoic]

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

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.

[Errata]

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.

[cob59]

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.

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 ?

[bountykiler]

Pour ma part

- concepts
Pas mal, mais c'est pas indispensable non plus.

- module
j'ai lu en vitesse la proposition. J'aime pas trop le fait de devoir à la fois utiliser des .mpp et des . h. En fait, j'ai l'impression que c'est la moins mauvaise solution que l'on ai trouvé pour le moment pour résoudre les problèmes de temps de compilation & co.

- filesystem
Oui, ce serai bien d'avoir une lib commune pour cela. Par ailleurs, j'ajouterai qu'il serai bon aussi d'ajouter une lib capable de gérer les accès réseau (gestion de sockets, résolution de noms & co) parce qu'a ma connaissance pour le moment, on continue de devoir passer par les functions issues du C.

- date
Oui, ça manque aussi.

- range, coroutine, mémoire transactionnelle,
pas lu de quoi il s'agissait.

- string_ref
De ce que je comprens, l'idée est d'encapsuler les std::string& et d'en profiter pour y ajouter des méthodes qui n'existent pas pour le moment (style trim, split, ...).
J'avoue que je vois pas trop l'intérêt.
Par ailleurs, quelqu'un peut-il me dire pourquoi des méthodes telles que trim ou split n'ont toujours pas été ajoutées aux std::string? Y'a-t-il une raison technique à cela? Parce que perso, je trouve que cela reste une lacune.

- Fixed-point arithmetic, digit seperator
Doit probablement être utile à certain.

- concurrent queue
Je dirai même plus : avoir un equivalent thread_safe pour chacun des containers de la stl (concurent_map, concurent_list,...).

- stream mutex
pas lu ce que c'était, mais doit probablement amener à plus de facilité/sécurité/efficacité.

- static_if :
J'y ajouterai bien des static_switch, voir même un static_while et un static_for. (bon je dis ça comme, reste à voir ce que cela donnerai en pratique).

- Rich_pointer
pas encore lu.

Sinon, quelques autres idées en vrac :
* lambda class
Un peu comme cela existe en C#. On pourrait faire des trucs du style :

Code :

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

1
2
3
4
5
6
7
8
9
 
auto createUser(dataRow& row)
{
  return {
    id = row["id"].toInt(), 
    name = row["name"].toString(), 
    age = row["age"].toInt() 
  }; 
};

* concurent algo.
par exemple une std::concurent_foreach qui exécuterai la fonction passée en paramètre dans un thread différent pour chaque element (avec éventuellement un paramètre qui donnerait le nombre max de thread, pour éviter de créer 10 000 threads par ex).

* comme déjà dit plus haut, ajout dans la stl de la gestion des sockets&co + ajout de méthodes dans la classe std::string!!! (trim, split, join, format, ...).

* Enfin, "last but not least" : ajout de capacités de reflection au compile-time

Ainsi pour sérialiser un objet, on pourrait faire un truc du style :

Code :

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

1
2
3
4
5
6
7
8
 
template<typename T>
serialize(std::ostream& stream, const T& obj)
{
  static_foreach(typename fieldInfo : typeof(T)::fields) {
    stream << fieldInfo::get_value(obj);
  };
}

(j'avoue sur ce coup là j'me suis laché )
L'idée est que l'operator typeof renvoie une classe générée par le compilo contenant entre autre un type fields qui est lui même une liste de type (à géré via la notion de nombre indéfini de paramètres templates j'imagine, sinon via l'introduction des typelist dans la norme), chacun étant capable par exemple de retourner la valeur du champ en question sur base de l'objet passé en paramètre.
Au final, la méthode ci-dessus permettrai de sérialiser facilement n'importe quel type d'objet.


Des avis?


EDIT : Je viens de lire le document N3326 : "Sequential access to data members and base sub-objects".
En fait, cela présente un autre moyen de faire ce que je décrivait dans mon dernier point, en permettant la représentation de n'importe quel objet sous la forme d'un tuple. Ce que j'aime là-dedans c'est que cela est géré au moment de la compilation, un peu comme mon idée.
Là-dessus, moi je dis

[Klaim]

Pour ma part

- concepts
Pas mal, mais c'est pas indispensable non plus.

Tu ne fais pas souvent de bibliothèques template pas vrai?

- module
j'ai lu en vitesse la proposition. J'aime pas trop le fait de devoir à la fois utiliser des .mpp et des . h. En fait, j'ai l'impression que c'est la moins mauvaise solution que l'on ai trouvé pour le moment pour résoudre les problèmes de temps de compilation & co.

Tu as peut être lu de travers : l'idée c'est d'ajouter un autre système optionel mais mailleurs que les headers. Les headers restent mais c'est juste pour permettre la rétro compatibilité et aussi pour certaines manipulations sioux qui n'ont d'interet qu'avec du code qui doit partiellement transiter vers les modules.

Les mpp sont censé être générés (et moi j'aimerai qu'ils soit lisibles par un programmeur C++...). Dans ton cpp tu auras toujours la séparation entre ce qui est pubilque (ce que tu mettais dans ton header) et ce qui est privé (ce que tu mettais exlcusivemetn dans ton cpp). Le mpp c'est un gros header pret a etre précompilé en somme. Dans ton code tu auras toujours ta séparation déclaration/définition, mais elle sera juste écrite différemment et n'impliquera pas les ouverture, parsing, re-parsing de fichiers imposés par le système actuel.

Donc sachant que le principal goulot d'étranglement de la compilation c'est ces ouvertures + parsing répétitifs mais nécessaires de fichiers, je trouve que c'est une très bonne solution.

Tu suggérerais quoi de meilleur?

- filesystem
Oui, ce serai bien d'avoir une lib commune pour cela. Par ailleurs, j'ajouterai qu'il serai bon aussi d'ajouter une lib capable de gérer les accès réseau (gestion de sockets, résolution de noms & co) parce qu'a ma connaissance pour le moment, on continue de devoir passer par les functions issues du C.

A ce que je sache, boost::asio a été proposé au standard avant C++11 donc ça doit être dans les libs à étudier. (et c'est très loin du C)


- range, coroutine, mémoire transactionnelle,
pas lu de quoi il s'agissait.

Range c'est en gros une pair d'itérateurs, de manière écrire plus facilement les manipulations de "range" de données.

Coroutines c'est en gros simuler des threads dans un seul vrai thread : on execute du code pendant un temps puis on arrete et on passe à un autre code. Très utile pour faire des languages de scripts, mais je sais pas trop pour le reste.

Mémoire transactionnelle, c'est tout simplement pouvoir dire qu'un bloc entier de code (de manipulations de la mémoier) doit se passer de manièer transactionnelle : quand on rentre dedans, on fait des modifs de la mémoire, mais elles ne sont toutes appliquées qu'une fois le bloc fini.
Ca permet aussi au thread d'executer le code, de blocker a cause d'un autre thread qui l'éxecute déjà, d'annuler ses modifs de mémoire, de revenir au départ, d'attendre un peut et de retenter le coup, sans que tu ais à coder quoi que ce soit à part dire que c'est un bloc transactionel.

En gros ça permet de faire du multithreading simple, safe, et surtout sans manipuler de lock ou de thread.

- concurrent queue
Je dirai même plus : avoir un equivalent thread_safe pour chacun des containers de la stl (concurent_map, concurent_list,...).

Ce n'est juste pas très utile, ça reviendrait a ajouter un bete mutex a chacun d'entre eux. Tu peux déjà le faire et de manière bien plus optimisée à ton cas spécifique.

Les conteneurs fait pour être concurrentiels ont des contraintes qui les rendent vraiment particulier et donc différent des conteneurs qu'on a actuellement. Voir la librarie de boost qui arrive qui fournie justement de tels conteneurs.

- static_if :
J'y ajouterai bien des static_switch, voir même un static_while et un static_for. (bon je dis ça comme, reste à voir ce que cela donnerai en pratique).

Jettes un oeil aussi à la version static if d'Alexandrescu et ses amis du language D (dans un autre des documents). C'est bien plus précis.

Static switch, il me semble qu'il y avait une bibliothèque de boost pas encore officiellement proposée qui le faisait, en tout cas oui ça serait sympas.

Par contre les boucles statiques... je pense pas que ce soit utile, mais je suis pas sur.

[bountykiler]

Tu ne fais pas souvent de bibliothèques template pas vrai?

ça m'arrive, mais c'est vrai que c'est pas l'essentiel de ce que je fais.

Tu as peut être lu de travers : l'idée c'est d'ajouter un autre système optionel mais mailleurs que les headers. Les headers restent mais c'est juste pour permettre la rétro compatibilité et aussi pour certaines manipulations sioux qui n'ont d'interet qu'avec du code qui doit partiellement transiter vers les modules.

Les mpp sont censé être générés (et moi j'aimerai qu'ils soit lisibles par un programmeur C++...). Dans ton cpp tu auras toujours la séparation entre ce qui est pubilque (ce que tu mettais dans ton header) et ce qui est privé (ce que tu mettais exlcusivemetn dans ton cpp). Le mpp c'est un gros header pret a etre précompilé en somme. Dans ton code tu auras toujours ta séparation déclaration/définition, mais elle sera juste écrite différemment et n'impliquera pas les ouverture, parsing, re-parsing de fichiers imposés par le système actuel.

Donc sachant que le principal goulot d'étranglement de la compilation c'est ces ouvertures + parsing répétitifs mais nécessaires de fichiers, je trouve que c'est une très bonne solution.

Tu suggérerais quoi de meilleur?

J'ai jamais dis que j'avais une meilleure idée . Seulement, la solution des modules ajoute de la compléxité je trouve, ce qui n'est pas top.
Sinon, il me semble avoir lu que les .mpp serait lisibles par un programmeur (ce qui serait mieux en effet).

A ce que je sache, boost::asio a été proposé au standard avant C++11 donc ça doit être dans les libs à étudier. (et c'est très loin du C)

Ce n'est juste pas très utile, ça reviendrait a ajouter un bete mutex a chacun d'entre eux. Tu peux déjà le faire et de manière bien plus optimisée à ton cas spécifique.

Les conteneurs fait pour être concurrentiels ont des contraintes qui les rendent vraiment particulier et donc différent des conteneurs qu'on a actuellement. Voir la librarie de boost qui arrive qui fournie justement de tels conteneurs.

Ben pour une liste, tu peux mettre un verrou par element par exemple. Pour les maps, y'a surement moyen de faire le même style de chose. Après, possible que cela engendre trop de contraintes qui les rendent inutilisable en pratique.
Je vais essayer de jeter un oeil du coté de boost.

Jettes un oeil aussi à la version static if d'Alexandrescu et ses amis du language D (dans un autre des documents). C'est bien plus précis.

Static switch, il me semble qu'il y avait une bibliothèque de boost pas encore officiellement proposée qui le faisait, en tout cas oui ça serait sympas.

Par contre les boucles statiques... je pense pas que ce soit utile, mais je suis pas sur.

Je disai cela comme ça, mais j'en pas sur non plus. En fait, je pense qu'il y a moyen de faire cela autrement, sans nécessiter l'ajout de mot clé à la norme.

Sinon j'ai aussi lu la doc concernant les rich pointer. Je dirai bof bof. Je préfère de loin la solution des "Sequential access to data members and base sub-objects". (les 2 propositions ciblent le même problème à la base, à savoir l'introspection de type).

[Emmanuel Deloget]

on pourrait enfin croiser un dev Java sans baisser les yeux.

Bah, il suffit de lui parler de string.compare() et c'est lui qui baisse les yeux, après un soupir et une petite phrase désespérée du type "je sais...".

A ce que je sache, boost::asio a été proposé au standard avant C++11 donc ça doit être dans les libs à étudier. (et c'est très loin du C)

J'espère juste que si asio passe dans le standard C++, le comité reverra le design parce qu'il reste des choses insupportable.

C++11 permet de se passer d'un grand nombre de ces horreurs, donc j'espère qu'on arrivera à quelque chose de correct.

[authchir]

J'espère juste que si asio passe dans le standard C++, le comité reverra le design parce qu'il reste des choses insupportable.

C++11 permet de se passer d'un grand nombre de ces horreurs, donc j'espère qu'on arrivera à quelque chose de correct.

Intéressant, à quoi fais-tu allusion en particulier?

[Klaim]

J'imagine qu'il parle de la conséquence d''avoir des lambda, move-semantic, type inférence, etc. Tout ce qui aide à mort syntactiquement parceque c'est vrai que tout le "bordel" a mettre en place en C++03 pour que asio marche rends le code un peut répulsif au premier regard.