IdentifiantMot de passe
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

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

Le , par gbdivers
45 commentaires

102PARTAGES

2  0 
Dans un billet daté d'hier, Herb Sutter confirme la mise en ordre de marche du groupe ISO WG21 travaillant sur la norme C++.

Cette réunion a été un succès, nous informe-t-il, avec des acteurs majeurs de l'industrie du logiciel (Microsoft, NVidia, Intel) prêts à intégrer des évolutions en avance de phase ! Ce qui confirme le retour en force du C++ dont on observe déjà les signes indicateurs depuis quelques temps.

Mais Herb nous prévient également que la nouvelle norme sera C++1y avec y==7. Il souligne cependant que l'objectif 2017 ne peut être atteint qu'en se concentrant sur une seule évolution majeure et ce malgré le nombre de propositions déjà avancées. Le premier tri ne devrait se faire qu'à la prochaine réunion en octobre.

Côté bibliothèques, le dynamisme devrait être plus important puisque des ajouts pourront avoir lieu entre deux normalisations. Bon espoir d'avoir prochainement quelque chose de natif pour gérer les fichiers (Boost.File System en standard ?) ou le réseau cite en exemple Herb Sutter.

Tout ceci se traduit par la mise en place de quatre groupes de travail chargés d'avancer dans certaines propositions :
  • SG1 : Concurrence et parallélisme
  • SG2 : Modules
  • SG3 : File System
  • SG4 : Réseau


Sources : Billet d’Herb Sutter, Comité de standardisation C++

Et vous ?

Puisqu'il ne faut en choisir qu'une, quelle devrait être l'évolution majeure de la prochaine session de normalisation ?

Cinq ans, est trop court ? Trop long ? Une bonne fréquence ?
Vous avez lu gratuitement 1 articles depuis plus d'un an.
Soutenez le club developpez.com en souscrivant un abonnement pour que nous puissions continuer à vous proposer des publications.

Une erreur dans cette actualité ? Signalez-nous-la !

45 commentaires
Commenter Signaler un problème
Joel F
Avatar de Joel F
Membre chevronné https://www.developpez.com
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
1  0 
Gugelhupf
Avatar de Gugelhupf
Modérateur https://www.developpez.com
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 ?
1  0 
gbdivers
Avatar de gbdivers
Inactif https://www.developpez.com
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
1  0 
Klaim
Avatar de Klaim
Membre expert https://www.developpez.com
Le 29/03/2013 à 11:00
Ca viens avec l'habitude et la curiosite.
1  0 
gbdivers
Avatar de gbdivers
Inactif https://www.developpez.com
Le 02/04/2013 à 8:04
Citation Envoyé par Gugelhupf Voir le message
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
Tu as aussi une mini-review faite par Emmanuel Deloget là des proposals pré-Bristol : http://www.developpez.net/forums/d13...l/#post7187861
1  0 
wirenth
Avatar de wirenth
Membre averti https://www.developpez.com
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é.
0  0 
barmic
Avatar de barmic
Membre actif https://www.developpez.com
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 : Sélectionner tout 
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.
0  0 
Klaim
Avatar de Klaim
Membre expert https://www.developpez.com
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...
0  0 
germinolegrand
Avatar de germinolegrand
Membre expert https://www.developpez.com
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.
0  0 
Klaim
Avatar de Klaim
Membre expert https://www.developpez.com
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...)
0  0 
Commenter Signaler un problème