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, Membre émérite
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 aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse

Avatar de Klaim Klaim - Membre expert https://www.developpez.com
le 27/01/2012 à 11:07
Citation Envoyé par bountykiler  Voir le message
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.
Avatar de bountykiler bountykiler - Membre régulier https://www.developpez.com
le 27/01/2012 à 14:27
Citation Envoyé par Klaim  Voir le message
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).
Avatar de Emmanuel Deloget Emmanuel Deloget - Expert confirmé https://www.developpez.com
le 28/01/2012 à 2:15
Citation Envoyé par cob59  Voir le message
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...".

Citation Envoyé par Klaim  Voir le message
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.
Avatar de authchir authchir - Membre du Club https://www.developpez.com
le 28/01/2012 à 3:44
Citation Envoyé par Emmanuel Deloget  Voir le message
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?
Avatar de Klaim Klaim - Membre expert https://www.developpez.com
le 28/01/2012 à 9:16
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.
Avatar de Niark13 Niark13 - Membre éclairé https://www.developpez.com
le 31/01/2012 à 10:48
J'apprécierais que les concepts soient écartés au profit de template constraints à la D, qui servent au final à la même chose, tout en étant beaucoup plus légers au niveau de la syntaxe et des changements à apporter au langage :

Pour ceux qui ne connaissent pas, les templates constraints sont un simple static if à la fin d'une déclaration de template qui conditionne leur instanciation :

Code : Sélectionner tout
1
2
3
4
5
 
template Toto(T) if condition 
{ 
    // code... 
}
si la condition n'est pas remplie, cette déclaration de Toto ne sera pas utilisée pour pour l'instanciation. La condition est evaluée à la compilation. Rien n'empêche d'avoir plus loin une autre déclaration d'un autre template homonyme, mais spécialisé avec des contraintes différentes.
Si aucune condition n'est trouvée, le compilateur émet une erreur indiquant qu'il n'a plus trouver de template à instancier.

Plus d'infos : http://erdani.com/d/new-stdio/concepts.html
Avatar de Klaim Klaim - Membre expert https://www.developpez.com
le 31/01/2012 à 11:44
Comme expliqué dans les propositions du commité, les concepts sont un mix de contraintes tel que dans D mais avec en plus une notion de sémantique.

Du coup théoriquement c'est plus expressif que des contraintes (et tu peux déjà voir l'interet avec ConceptClang).
Avatar de Emmanuel Deloget Emmanuel Deloget - Expert confirmé https://www.developpez.com
le 31/01/2012 à 15:01
Citation Envoyé par Klaim  Voir le message
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.

Il n'y a pas que le code qui soit un peu répulsif - de toute façon, si asio fait un jour partie de la librairie standard, on aura pas besoin de regarder le code. Il y a plein de choses dans le design d'asio qui ne me plaisent pas, mais alors pas du tout. En voici quelques exemples :

* l'utilisation nécessaire de shared_ptr dès lors qu'on traite des sockets dans une thread qui ne l'a pas créé (ce qui arrive fréquemment, dès lors qu'on fait un programme multi-threadé ou les connections entrantes sont gérées par un pool de thread) . Ce point a été récemment limité avec l'arrivée d'une sémantique de déplacement dans les sockets. A noter quand même que la sémantique de déplacement existait déjà en C++ avant l'introduction des move ctor : il suffisait de créer un constructeur "par copie" dont l'argument n'était pas const. C'est ce que faisait auto_ptr<>. Le résultat n'est pas safe dans tous les cas, mais ça a toujours été possible).

* certains objets qui n'encapsulent en fait qu'une seule fonction (avec des variantes d'implémentation). cf les classes resolver (dans ce cas précis, une fonction libre aurait été plus approprié).

* les noms d'objet qui n'ont pas de sens (exemple : io_service ; rien qu'en lisant le nom, est-ce que quelqu'un peut me dire ce que ça fait ?), ou qui engendrent une confusion avec le nom de la fonction qu'ils encapsulent (cf. les classes acceptor, qui ne font pas que l'accept() - loin de là). Cette clase est en fait pire que ça : acceptor::listen ne fait pas de listen mais mets la socket dans un état qui lui permet d'être utilisé pour faire un listen, et acceptor::accept ne fait pas le polling (qui est en fait fait par io_service).

* la gestion des io async/sync : les sockets ont des méthodes read et read_async, et l'une d'elle n'a pas de sens. Certains OS ne permettent pas la création de sockets utilisable simultanément dans les deux modes (par exemple, les OS POSIX l'autorise, mais pas Windows). Dans le princpipe, de toute façon, une socket async n'est pas une socket sync, et il n'y a pas de raison que le type de l'objet soit le même (ou pire, que la vérification de la possibilité du traitement se fasse au runtime).

Il y a encore d'autres points mineurs, mais je ne vais pas faire un inventaire à la Prévert

Après, il y a de bonnes idées : les strand, l'idée de base sur les endpoint, etc. Mais tout n'est pas bon à manger dans asio.
Avatar de Klaim Klaim - Membre expert https://www.developpez.com
le 06/02/2012 à 21:12
Emmanuel> Merci pour les feedbacks! Donc ya pas que moi qui trouve cela étrangement difficile à comprendre, surtout à cause du nommage...

Sinon, il y en a ici qui participent au premier rdv post-C++11 du commité. Si oui ça serait cool qu'on ai des infos sur ce qui se dit...
Avatar de Klaim Klaim - Membre expert https://www.developpez.com
le 06/02/2012 à 21:47
Citation Envoyé par Klaim  Voir le message

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 : Sélectionner tout
reflect class MaClass  { ...}
Mais bon j'ai pas encore tout lu...

Dean Micheal Berris réponds à mes interrogations sur son blog:

http://www.cplusplus-soup.com/2012/0...-pointers.html
http://www.cplusplus-soup.com/2012/0...tly-asked.html
Avatar de Niark13 Niark13 - Membre éclairé https://www.developpez.com
le 07/02/2012 à 12:13
Citation Envoyé par Klaim  Voir le message
Comme expliqué dans les propositions du commité, les concepts sont un mix de contraintes tel que dans D mais avec en plus une notion de sémantique.

Du coup théoriquement c'est plus expressif que des contraintes (et tu peux déjà voir l'interet avec ConceptClang).

Je ne le nie pas, les concepts vont plus loin. Après, il faut voir si le coût en complexification du langage est justifié ou non par rapport aux contraintes à la D, qui est une solution très simple, surtout si static if entre aussi dans le langage, puisqu'elle repose sur le même mécanisme.

C'est la première question à laquelle Bjarne Stroustrup a eu à répondre après son talk GoingNative 2012 (http://channel9.msdn.com/Events/Goin...-Design-for-C-), et visiblement, la réponse est loin d'être évidente...
Offres d'emploi IT
Ingénieur développement fpga (traitement vidéo) H/F
Safran - Ile de France - 100 rue de Paris 91300 MASSY
Expert décisionnel business intelligence H/F
Safran - Ile de France - Évry (91090)
Consultant sap finance/controlling H/F
Safran - Ile de France - Vélizy-Villacoublay (78140)

Voir plus d'offres Voir la carte des offres IT
Contacter le responsable de la rubrique Accueil