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 24/01/2012, par Arzar, Membre Expert
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 ) ?

Les rubriques (actu, forums, tutos) de Développez


Poster une réponse Retrouver la discussion sur le forum

Avatar de bountykiler bountykiler
Membre du Club
le 27/01/2012

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.


Citation:




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


Citation:




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)




Citation:




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.


Citation:




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é
le 28/01/2012

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
Nouveau Membre du Club
le 28/01/2012

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
le 28/01/2012
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 confirmé
le 31/01/2012
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 :



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
le 31/01/2012
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é
le 31/01/2012

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
le 06/02/2012
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
le 06/02/2012

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 :



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 confirmé
le 07/02/2012

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...
Poster une réponse Retrouvez la suite de la discussion

 
 
Developpez.com

Nous contacter

Participez

Informations légales

 
Services

Forum d'entraide

Blogs

Hébergement

 
Partenaires

Hébergement Web