L'évolution du langage C++ s'accélère
10 groupes d'études et plusieurs nouvelles dates de sortie pour les prochaines normes

Les rubriques (actu, forums, tutos) de Développez
Tags
Réseaux sociaux


 Discussion forum

Retrouvez le dossier complet de la rédaction
Le , par gbdivers, Inactif
L'évolution du langage C++ s'accélère
10 groupes d'études et plusieurs nouvelles dates de sortie pour les prochaines normes


Depuis la première annonce l'année dernière, le comité à fait plein de petits bébés : la famille s'est agrandie et compte maintenant 10 SG (study group), 4 WG (working group) et un comité.



Les working groups ont pour rôle de proposer les modifications à apporter à la norme, modifications qui seront approuvées, ou non, par le comité de normalisation.

  • le core working group (CWG) a la charge des corrections sur le langage (chapitres 1 à 16 de la norme) ;
  • l'evolution working group (EWG) travaille sur l'évolution du langage (travaux qui sont délégués aux study groups) ;
  • le library working group (LWG) s'occupe de le maintenance de la bibliothèque standard (chapitres 17 et suivants de la norme) ;
  • le library evolution working groupe (LEWG) est responsable de l'évolution de la bibliothèque standard (travaux qui sont délégués aux study groups).


Les study groups ont la charge d'étudier les évolutions du langage (SG 1, 2, 5, 7, 8 et 10) et de la bibliothèque (SG 3, 4, 6 et 9) sur des thèmes spécifiques et de proposer des modifications de la norme aux WG :
  • SG1 Concurrency : concurrence et parallélisme ;
  • SG2 Modules : utilisation de modules à la place du système d'en-têtes ;
  • SG3 File System : gestion des fichiers (basé sur Boost.Filesystem v3) ;
  • SG4 Networking : gestion du réseau, sockets et HTTP ;
  • SG5 Transactional Memory : mémoires transactionnelles (mémoire permettant de créer un ensemble indivisible d'écriture et lecture) ;
  • SG6 Numerics : analyse numérique, nombres réels fixes et flottants, fractions ;
  • SG7 Reflection : réflexion à la compilation ;
  • SG8 Concepts : ajout de contraintes sur les types ;
  • SG9 Ranges : alternative aux itérateurs ;
  • SG10 Feature Test : standardisation des tests.


Au niveau du planning, le comité s'active, avec plus d'une centaine de propositions pour le congrès de Bristol (voir la discussion [ISOC++] Mailing pre-Bristol). En plus de la prochaine norme qui devrait sortir en 2017, le comité prévoit des Technical Specifications, pour les ajouts de fonctionnalités indépendantes, et une révision mineure de la norme en 2014.



Quelles sont les fonctionnalités qui vous intéressent le plus ? Celles que vous auriez aimer avoir ?
Que pensez-vous de l’accélération prise par le comité pour le langage et la bibliothèque standard ?


Source : http://isocpp.org/std/the-committee


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse

Avatar de wirenth wirenth
http://www.developpez.com
Membre éclairé
le 21/03/2013 12:05
Modules et concepts, c'est ce qui m'arrangerait le plus. Et c'est ce qui nécessite les plus gros changements en profondeur dans le langage.
Network et FileSystem sont bien représentés dans Boost, ce n'est pas la priorité.
Avatar de barmic barmic
http://www.developpez.com
Membre actif
le 21/03/2013 13:57
Citation Envoyé par rakotoarisoatahiana  Voir le message
On devrait avoir des pointeurs sur des classes, surtout pour les débutants.
Ex : listes chaînées :
Code :
1
2
3
4
5
template<class t> 
class list { public : 
   t info ; 
   list suiv ; 
}*

Je ne pense pas que ce soit envisageable simplement parce que ça entraine d'énormes refonte dans le langage.

Pour ceux qui n'ont pas compris de quoi il s'agit les pointeurs de classe ça permet, par exemple de passer une classe en paramètre d'une méthode et celle-ci peut entre autre instancier des objets de cette classe.

C'est à mon avis pas faisable à cause du fait que les classes templates sont du code généré et c'est un problème qui, en C++, s'adresse avec les templates justement.
Avatar de Klaim Klaim
http://www.developpez.com
Expert Confirmé
le 21/03/2013 14:11
Citation Envoyé par barmic  Voir le message
Je ne pense pas que ce soit envisageable simplement parce que ça entraine d'énormes refonte dans le langage.

Pour ceux qui n'ont pas compris de quoi il s'agit les pointeurs de classe ça permet, par exemple de passer une classe en paramètre d'une méthode et celle-ci peut entre autre instancier des objets de cette classe.

C'est à mon avis pas faisable à cause du fait que les classes templates sont du code généré et c'est un problème qui, en C++, s'adresse avec les templates justement.

De loin je dirais que ca n'a aucun interet parcequ'on peut deja faire la meme chose en C++.

D'abord, via les template on peut avoir le type en question. Si on veut des infos au runtime on peut utiliser type_index pour identifier le type. Si tu veux faire une manip specifique avec le type, genere un lambda qui le manipule et mets le dans une map.
Enfin bref, ya trop de moyens de se passer de "pointeurs de classe".

Et j'imagine que ca sera encore plus simple si les gros chantiers cote reflexion (qui sont a priori necessaires pour rendre le networking attractif) sont mis en place. Par contre apparement ca va pas etre pour tout de suite...
Avatar de germinolegrand germinolegrand
http://www.developpez.com
Expert Confirmé Sénior
le 21/03/2013 15:46
Très clairement pour moi File System, Networking et Ranges sont les seuls à m'intéresser.

Les modules ça a l'air cool comme ça, mais ça rajoute un truc à apprendre parce que c'est pas comme si ça remplaçait les #include. Bon, ça accélère la compilation sans affecter les performances du résultat je crois, donc je suis pas contre. Mais ça ne m'intéresse pas plus que ça, si ça y est pourquoi pas si ça y est pas je m'en passe fort bien.

Pour le reste je suis pas contre mais je n'en ai pas besoin.

Passons donc à ce qui m'intéresse .

Le File System, ça y'en a besoin. Clairement. La gestion des fichiers en C++ c'est une boucherie. (Si au passage ils pouvaient améliorer les stream je serais pas contre mais je rêve pas faudrait une modification du langage pour ça).

Le Networking : de la standardisation là dessus ça peut pas faire de mal, c'est le foutoir pardonnez moi l'expression.

Pour les ranges, je m'intéresse à la question parce que je travaille bien plus souvent sur des conteneurs complets que sur une partie (voire toujours, sauf si l'algo est vraiment tordu/optimisé à mort). De plus, il faudrait qu'il soit simple de fournir des ranges dans l'interface d'une classe, chose qui n'est pas vraiment agréable avec les itérateurs.
Avatar de Klaim Klaim
http://www.developpez.com
Expert Confirmé
le 21/03/2013 16:14
Citation Envoyé par germinolegrand  Voir le message
Les modules ça a l'air cool comme ça, mais ça rajoute un truc à apprendre parce que c'est pas comme si ça remplaçait les #include. Bon, ça accélère la compilation sans affecter les performances du résultat je crois, donc je suis pas contre. Mais ça ne m'intéresse pas plus que ça, si ça y est pourquoi pas si ça y est pas je m'en passe fort bien.

Je sais pas pour toi mais perso le probleme N1 du C++ en pratique c'est bien la lenteur de la compilation, meme apres avoir fais en sorte de minimiser les degats.

L'autre truc c'est qu'q priori les module vont justement retirer la necessite de comprendre pas mal de trucs lies aux headers (si ils vont par la solution sans headers mais c'est pas clair ou on en est...)
Avatar de guillaume07 guillaume07
http://www.developpez.com
Débutant
le 21/03/2013 16:57
avec les modules il n'y aurait plus de définition séparée de l'implementation ?
Avatar de Klaim Klaim
http://www.developpez.com
Expert Confirmé
le 21/03/2013 18:17
Citation Envoyé par guillaume07  Voir le message
avec les modules il n'y aurait plus de définition séparée de l'implementation ?

Si, ca n'impacte pas le code lui meme, juste comment il est encapsule.
Actuellement il y a deux grandes lignes pour les modules et ce qui est pas clair c'est ou on en est aujourd'hui (ya rien dans la derniere liste de papiers).
La premiere direction c'est simplement de faire en sorte que les fichiers generes par le compilateur a partir de la compilation du module, soient lisible par un humain, ce qui fait qu'en gros on aura plus besoin de headers puisque ces fichiers ne contiendraient que les interfaces publiques (et inline) du code du module en question. Mais cela est tellement radical que l'autre direction plus "pragmatique" mais peut etre pas incompatible serait de garder les headers et de s'en servir aussi dans le systeme de modules, mais de virer les commandes #include.

Enfin bref, on a trop peu d'info depuis la fin de l'annee derniere sur l'avancee de cette feature malheureusement.
Avatar de zartc zartc
http://www.developpez.com
Invité de passage
le 23/03/2013 19:16
Citation Envoyé par Klaim  Voir le message
Si, ca n'impacte pas le code lui meme, juste comment il est encapsule.

Ouaip, en fait pour moi les modules ça n'aurrait d'intérest que si ça permet de se passer complètement des headers. D'autre langages l'on fait et franchement ça allège vraiment les choses.
Avatar de gbdivers gbdivers
http://www.developpez.com
Inactif
le 23/03/2013 19:32
Citation Envoyé par zartc  Voir le message
Ouaip, en fait pour moi les modules ça n'aurrait d'intérest que si ça permet de se passer complètement des headers. D'autre langages l'on fait et franchement ça allège vraiment les choses.

Pour rappel, la séparation du code dans un fichier header et un fichier d'implémentation n'est pas une obligation. Cela se justifie surtout pour une question de design. Donc si tu veux pas séparer ton code, ne le fais pas (mais c'est moins propre)
Avatar de Kalith Kalith
http://www.developpez.com
Membre expérimenté
le 24/03/2013 12:15
Je me demandais s'il serait réalisable d'ajouter un overload de l'opérateur '.', de façon à rendre transparente l'utilisation de certains wrappers comme reference_wrapper<T> :
Code :
1
2
3
4
5
6
7
8
9
10
struct test { 
    void foo() {} 
}; 
 
test t; 
 
// Norme actuelle 
std::reference_wrapper<test> trw(t); 
trw.foo(); // error 
trw.get().foo(); // ok
Ou alors, puisque c'est l'idée sous-jacente, supporter de manière transparente les conteneurs de références d'une manière ou d'une autre :
Code :
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
std::vector<test&> v; 
test t1, t2; 
v.push_back(t2); 
v.push_back(t1); 
 
for (auto& t : v) { 
    t.foo(); 
} 
 
// Une implémentation possible actuellement (pseudo code) : 
using std::vector<T&> = std::vector<std::reference_wrapper<T>> 
// Seul inconvénient : 
for (auto& t : v) { 
    t.foo(); // error: 'auto' = std::reference_wrapper<T> 
    t.get().foo(); // ok 
} 
 
v[0].foo(); // error 
v[0].get().foo(); // ok
Dans le fond, c'est comme un conteneur de pointeurs si ce n'est que
  1. on a la "garantie" de ne pas avoir de nullptr dans le conteneur (sauf si on veut être mauvais : v.push_back(*(test*)nullptr);, c'est donc une garantie sémantique plutôt que technique),
  2. on bénéficie de la notation "objet" plutôt que "pointeur", ce qui peut être plus simple pour les débutants (et un caractère de moins à taper, c'est toujours ça de pris pour tout le monde).
Avatar de Jean-Marc.Bourguet Jean-Marc.Bourguet
http://www.developpez.com
Expert Confirmé Sénior
le 24/03/2013 12:57
Citation Envoyé par Kalith  Voir le message
Je me demandais s'il serait réalisable d'ajouter un overload de l'opérateur '.',

Ça fait partie des choses régulièrement suggérées pour lesquelles personne n'a à ma connaissance déjà fourni une proposition complète. Dans le même genre il y a des propositions de rendre interchangeable x.f(a,b,c) et f(x,a,b,c).
Avatar de Arzar Arzar
http://www.developpez.com
Membre Expert
le 24/03/2013 14:51
Citation Envoyé par Klaim  Voir le message
Enfin bref, on a trop peu d'info depuis la fin de l'annee derniere sur l'avancee de cette feature malheureusement.

Pour info il y a quelques jours un gros pavé de doc décrivant l'implémentation (toujours en travaux) des modules dans clang a été commité :
http://llvm.org/svn/llvm-project/cfe...cs/Modules.rst
Il n'y a rien de définitif bien sur, mais ça donne une bonne idée de ce qui va être proposé au comité pour l'approche numéro 2 ("headers remain the truth")

Citation Envoyé par Jean-Marc.Bourguet
Ça fait partie des choses régulièrement suggérées pour lesquelles personne n'a à ma connaissance déjà fourni une proposition complète. Dans le même genre il y a des propositions de rendre interchangeable x.f(a,b,c) et f(x,a,b,c).

Il me semble que cette feature est disponible en D depuis quelques temps maintenant, du coup je me demande quel est l'opinion des programmeurs D à ce sujet ?
Avatar de Kaluza Kaluza
http://www.developpez.com
Membre habitué
le 24/03/2013 17:29
Citation Envoyé par Jean-Marc.Bourguet  Voir le message
Dans le même genre il y a des propositions de rendre interchangeable x.f(a,b,c) et f(x,a,b,c).

Alors ça je n'y avais jamais pensé ... mais qu'est-ce que ça serait bien !
Plus de réflexions interminable sur le fait de choisir si tel fonctionnalité doit passer par une fonction membre ou par une fonction libre

Tu as un exemple de mailing avec cette proposition ?
Tu as une page d'explication de cette fonctionnalité en D ?
Avatar de JolyLoic JolyLoic
http://www.developpez.com
Rédacteur/Modérateur
le 24/03/2013 19:10
J'ai entendu des gens en parler, mais je n'ai pas mémoire de propositions (je n'ai pas encore lu le mailing de Bristol). Il y a des oppositions à ça aussi, car ça risque d'accroitre encore plus les conflits et collisions. Quand on fait a.f(), on sait très bien où chercher f, ce qui n'est pas le cas quand on fait f(a), et pose plein de problèmes.
Avatar de Klaim Klaim
http://www.developpez.com
Expert Confirmé
le 24/03/2013 20:34
Citation Envoyé par Arzar  Voir le message
Pour info il y a quelques jours un gros pavé de doc décrivant l'implémentation (toujours en travaux) des modules dans clang a été commité :
http://llvm.org/svn/llvm-project/cfe...cs/Modules.rst
Il n'y a rien de définitif bien sur, mais ça donne une bonne idée de ce qui va être proposé au comité pour l'approche numéro 2 ("headers remain the truth")

Ah! Merci pour l'info!
Avatar de Jean-Marc.Bourguet Jean-Marc.Bourguet
http://www.developpez.com
Expert Confirmé Sénior
le 24/03/2013 21:00
Citation Envoyé par JolyLoic  Voir le message
J'ai entendu des gens en parler, mais je n'ai pas mémoire de propositions (je n'ai pas encore lu le mailing de Bristol). Il y a des oppositions à ça aussi, car ça risque d'accroitre encore plus les conflits et collisions. Quand on fait a.f(), on sait très bien où chercher f, ce qui n'est pas le cas quand on fait f(a), et pose plein de problèmes.

C'est dans le même genre d'idées en l'air depuis longtemps que je n'ai jamais vues concrétisées.
Avatar de Pierre le Grand Pierre le Grand
http://www.developpez.com
Invité de passage
le 27/03/2013 4:25
Un équivalent d'AWT ou de Swing qui rendrait C++ portable sur tous les OS graphiques serait le bienvenue.

Il suffirait de reprendre la devise de Lazarus: write ounce, compile anywhere. Un équivalent C++ serait très utile par ce que point de vue langage, Lazarus est faible. Par exemple, ses arbres AVL contiennent des pointeurs sans type (void * en C++) ce qui n'offre aucune sécurité de type.
Avatar de Joel F Joel F
http://www.developpez.com
Membre Expert
le 27/03/2013 7:47
bof bof SWING++, les gui franchement c'est le sloppery sloep infame: impossible a cocneptualiser et a mettre dans des composants generiques propres et sans API dementes. Y a regulierement des propal sur boost par exemple, et c'est le drame a chaque fois.

Pour operator. y a un N-paper mais je trouve plus le numero. Y a quelqu'un qui a un talk sur un imple clang a C++Now je crois aussi
Avatar de gbdivers gbdivers
http://www.developpez.com
Inactif
le 27/03/2013 9:55
+1 pour ne pas avoir de gui dans la norme, tout au moins pas avant des années. Il y a trop de gros frameworks graphiques qui ont une API complètement différentes pour arriver à normaliser quoi que ce soit. Il vaut mieux que le comité se concentre sur d'autres choses.
Et en plus, C++ est portable sans interface graphique. Et il existe des frameworks pour les interfaces graphiques portables. Il faudra bien finir par comprendre que la philosophie du C++ n'est pas de normaliser tout dans le langage et la bibliothèque standard, contrairement à d'autres langages. Le C++ a un écosystème très important, utilisez le
Avatar de Klaim Klaim
http://www.developpez.com
Expert Confirmé
le 27/03/2013 10:00
Citation Envoyé par Joel F  Voir le message
bof bof SWING++, les gui franchement c'est le sloppery sloep infame: impossible a cocneptualiser et a mettre dans des composants generiques propres et sans API dementes. Y a regulierement des propal sur boost par exemple, et c'est le drame a chaque fois.

En fait en se penchant sur les raisons purement lies a la psychologie humaine, on se rends compte qu'on peut pas faire un systeme generique pour representer graphiquement des informations. Au mieu on peut dire quelles sont les informations a representer et quelles actions on peut faire avec (en gros ce qu'on a avec le code...). Des qu'on touche a l'aspect, le seul moyen d'etre precis c'est d'avoir un language separe, comme XAML ou meme HTML ou quelque chose dans ce genre.

Du coup effectivement ca risque pas d'arriver de si tot d'avoir un systeme de GUI. Je pense qu'on risque d'avoir plus de changes de se retrouver avec une lib gerant DOM (yavait une proposition l'annee derniere) et une specialisation pour HTML ensuite.

Ou alors peut etre que microsoft arriverai a faire passer son XAML ou un equivalent.

Enfin bref, les GUI c'est la merde.

Surtout quand on pense que aujourd'hui, les interfaces ne sont plus seuleemtn graphiques. Au final il faudrait faire une abstraction input/output, ce qui serait utile pour maper des donnees et fonctions avec une implementation d'interface homme/machine particuliere, le mapping se faisant via une bibliotheque standard, que de proposer une bibilotheque precise pour gerer tout ca.
Enfin c'est mon point de vue.
Avatar de Gugelhupf Gugelhupf
http://www.developpez.com
Membre Expert
le 27/03/2013 13:24
Avant, je me disais aussi que le C++ devrait avoir son AWT ou Swing, avec le temps j'ai compris que ça ne servirait à rien.
Au début en Java on avait AWT, on est passé à Swing pour avoir des composants plus léger, puis aujourd'hui le standard c'est JavaFX.
Rendre AWT ou Swing standard ça ne sert à rien car ce sont des outils qui évoluent avec le temps.
Le C++ a déjà Qt, et c'est très bien comme c'est.

Perso j'aimerais bien avoir Module, Networking et FileSystem en C++, et j'aimerais que ce soit des API simples et intuitif à manipuler.
Par contre j'ai vu la spec de Module et ça m'inquiète un peu avec les "export", j'aimerais bien que ce soit aussi simple qu'en C# avec l'utilisation des namespace.

Java => package/import
C# => namespace/using
C++ => namespace/import ?
Avatar de Kalith Kalith
http://www.developpez.com
Membre expérimenté
le 28/03/2013 22:08
Citation Envoyé par Joel F  Voir le message
Pour operator. y a un N-paper mais je trouve plus le numero. Y a quelqu'un qui a un talk sur un imple clang a C++Now je crois aussi

J'ai pu trouver celui-ci (N1671) mais il date de 2004.
Avatar de Emmanuel Deloget Emmanuel Deloget
http://www.developpez.com
Expert Confirmé Sénior
le 29/03/2013 0:34
Citation Envoyé par gbdivers  Voir le message
+1 pour ne pas avoir de gui dans la norme, tout au moins pas avant des années. Il y a trop de gros frameworks graphiques qui ont une API complètement différentes pour arriver à normaliser quoi que ce soit. Il vaut mieux que le comité se concentre sur d'autres choses.
Et en plus, C++ est portable sans interface graphique. Et il existe des frameworks pour les interfaces graphiques portables. Il faudra bien finir par comprendre que la philosophie du C++ n'est pas de normaliser tout dans le langage et la bibliothèque standard, contrairement à d'autres langages. Le C++ a un écosystème très important, utilisez le

C'est surtout, selon moi, que les systèmes graphiques sont différents au niveau conceptuels, avec de nombreuses et subtiles différences de comportement. Du coup, les mettre sous une même bannière reviendrait à les obliger à utiliser les même concepts, ce qui voudrait dire au final que les implémentations n'auraient pas le choix.

Ca ne serait pas très fin, et ça retarderait bien le développement de nouvelles solutions graphiques (celles-ci évoluent plus vite que la librairie standard).

Et même si cette option délicate est choisie, quel modèle de GUI utiliser ?

* immediate GUI (on doit appeler à chaque frame la fonction draw() d'un objet graphique pour qu'il se dessine ; très utile dans le jeu vidéo)
* GUI évenementiel (à la Windows)

Et encore après, quel comportement ?

* c'est l'OS qui dessine la GUI ?
* c'est la librairie qui dessine la GUI ?
* on utilise un mix des deux ?
* quid des décorations server-side (sur XWindow) / client-size (sur Wayland) ?
* faut-t-il un serveur ?
* qui s'occupe de la composition de l'écran ?
* ...

Bref : il y a plus que des points chauds - c'est quasiment tâche impossible, à moins de fixer des limites et donc de limiter les fonctionalités et l'évolutivité des GUI.
Avatar de Garuda Garuda
http://www.developpez.com
Membre Expert
le 29/03/2013 9:43
bof bof SWING++, les gui franchement c'est le sloppery sloep infame: impossible a cocneptualiser et a mettre dans des composants generiques propres et sans API dementes. Y a regulierement des propal sur boost par exemple, et c'est le drame a chaque fois.

Pour operator. y a un N-paper mais je trouve plus le numero. Y a quelqu'un qui a un talk sur un imple clang a C++Now je crois aussi

Nom de zeus ! Quelqu'un peut traduire ?
Avatar de gbdivers gbdivers
http://www.developpez.com
Inactif
le 29/03/2013 10:02
bof bof SWING++, les gui franchement c'est le sloppery sloep infame: impossible a cocneptualiser et a mettre dans des composants generiques propres et sans API dementes. Y a regulierement des propal sur boost par exemple, et c'est le drame a chaque fois.

Pour operator. y a un N-paper mais je trouve plus le numero. Y a quelqu'un qui a un talk sur un imple clang a C++Now je crois aussi

Bof, bof, SWING++. Les interfaces graphiques, franchement, c'est une pente glissante infâme à conceptualiser et à mettre dans ces composants génériques propres et sans interfaces démentes. Il y a régulièrement des propositions sur Boost par exemple et c'est le drame à chaque fois.

Bon, à part quelques fautes de frappes et l'absence d'accent (ce qui arrive régulirèment pour ceux qui ont des claviers QWERTY), c'était compréhensible comme message
Avatar de Gugelhupf Gugelhupf
http://www.developpez.com
Membre Expert
le 29/03/2013 10:21
Bonjour,

J'ai trouvé un lien (via isocpp.org) avec des N-paper sur C++14.

Je vous avouerais que je n'ai pas saisi la moitié des specs
Avatar de Klaim Klaim
http://www.developpez.com
Expert Confirmé
le 29/03/2013 11:00
Ca viens avec l'habitude et la curiosite.
Offres d'emploi IT
Ingénieur en développement mobile ios
CDI
Easy Partner - Ile de France - Paris (75000)
Parue le 25/11/2014
Responsable support technique applications h/f
CDI
Société Générale France - Ile de France - Paris (75000)
Parue le 13/11/2014
Développeur Chef de projet PHP SYMFONY (H/F)
CDI
AVANIM - Rhône Alpes - LYON (69007)
Parue le 06/11/2014

Voir plus d'offres Voir la carte des offres IT
 
 
 
 
Partenaires

PlanetHoster
Ikoula