Le draft de la prochaine norme C++14 est disponible
Le résumé des nouvelles fonctionnalités par germinolegrand

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


 Discussion forum

Le , par Community Management, Community Manager
C++14 est la prochaine norme prévue pour le C++ en 2014, ce depuis l'annonce du planning en novembre 2012.

La norme C++14 ne sera qu'une modification mineure du langage, visant essentiellement à combler les défauts et les lacunes de la norme C++11 (avec tout de même quelques ajouts de fonctionnalités). Aussi ne contient-elle pas de modifications majeures du langage, pour lesquelles il faudra attendre C++17.

Le nouveau draft est consultable au format PDF sur isocpp.org : N3690.pdf.

Il a été approuvé lors du meeting de Bristol durant laquelle les membres du comité ont voté un à un les ajouts faits à ce CD (Committee Draft).

Les derniers ajouts votés sont notamment :


Et maintenant ? Le CD va maintenant passer au ballotage des NB (National Bodies, soit les représentants nationaux) qui durera trois mois.

Le prochain meeting aura lieu fin septembre à Chicago, où si tout se passe bien le CD deviendra un Draft International Standard (DIS), autrement dit le brouillon du prochain standard. Après le DIS vient le ballotage du JTC qui durera 5 mois, puis 2 mois supplémentaires si le ballotage est approuvé, ce qui conduit à la signature de l'International Standard (IS), prévue en été 2014. En cas d'échec lors d'une de ces étapes il sera nécessaire de produire un nouveau CD, ce qui repousse à fin 2014 voir plus loin la signature de l'IS final.

En parallèle se poursuivent les Technical Specifications (TS - filesystem, networking, concurrency, etc.) et les proposals pour C++1y qui sera cette fois une nouvelle version majeure du langage comme C++11 l'a été pour C++98.

Votre opinion
Suivez-vous avec intérêt l'évolution du C++ ?
Les ajouts votés vous paraissent-t-ils intéressants ?

Sources
isocpp.org - le draft C++14
isocpp.org - rapport du meeting
Commentaire de M. Wong
isocpp.org - ISO/IEC JTC1 Procedures


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


 Poster une réponse

Avatar de Neckara Neckara
http://www.developpez.com
Responsable Sécurité
le 17/05/2013 7:49
Bonjour,

Citation Envoyé par germinolegrand  Voir le message
Suivez-vous avec intérêt l'évolution du C++ ?

On ne peut pas vraiment dire que je suis l'évolution du C++ pourtant c'est une chose que je trouve vraiment intéressante.
Citation Envoyé par germinolegrand  Voir le message
Les ajouts votés vous paraissent-t-ils intéressants ?

J'ai regardé vite fait, std::quote me semble assez pratique, std::optionnal nous permettra d'éviter de jouer avec les pointeurs quand on ne veut pas transmettre de valeurs, bref, il y a pas mal de petites choses^^

Par contre je trouve qu'il manque des fonctionnalité plus "haut niveau" dans le C++ STL comme un std::plugin (manipuler/charger des plugins) ou une fonction permettant d'avoir la liste des serveurs DNS utilisés par l'ordinateur, accéder à des bases de données en renseignant le pilote à utiliser, etc.
Heureusement boost (loué soit-il) permet déjà de compléter pas mal le C++ ne serait-ce que pour les sockets (std::socket n'existant pas encore à ma connaissance).

Je pense donc que le C++ n'a pas encore fini de s'améliorer.
Avatar de Linunix Linunix
http://www.developpez.com
Membre expérimenté
le 17/05/2013 9:16
"Suivez-vous avec intérêt l'évolution du C++ ?"
Tout Neckara, je ne suis pas vraiment, j'essaye juste de me mettre à la page, et utiliser ce qui me sert...

"Heureusement boost (loué soit-il) permet déjà de compléter pas mal le C++ ne serait-ce que pour les sockets (std::socket n'existant pas encore à ma connaissance"

Oui, en effet, heureusement que Boost est la pour completer la STL, Mais nous savons toi, comme moi, que la STL va intégrér std::socket lors du C++17
Tout comme ce qui s'est passé avec les threads les threads de boost, sont devenus les threads de la STL

"Je pense donc, que le C++ n'a pas fini de s'ameliorer"

Mhhh, disons que les changements entre le C++11 et la prochaine norme ne seront pas énormissimes, tout comme ce qui s'est passé avec la norme 98, et 2003
Je pense donc, qu'on pourra réelement parler d'une evolution majeure avec la Norme du C++17

Cela dit, j'attendais peut être un peu le "std::process"
Avatar de gbdivers gbdivers
http://www.developpez.com
Inactif
le 17/05/2013 9:52
Suivez-vous avec intérêt l'évolution du C++ ?

Avec beaucoup d'attention (ne serait-ce que pour informer les lecteurs du forum)

On avait déjà discuter sur le forum de l'absence de certaines fonctionnalités du C++11, comme make_unique (pour supprimer définitive new et par symétrie avec make_shared), optional (pour une gestion plus fine des erreurs dans les retour de fonctions) ou des lambdas génériques.
J'aime beaucoup aussi les améliorations permettant de simplifier l'écriture du code, comme l'utilisation de auto en retour de fonction ou la simplification de l'utilisation des traits.
Pour shared_mutex et exchange, Emmanuel Deloget va peut être nous écrire un article là dessus ? (maintenant qu'il a commencé une série d'articles sur les theads en C++ )

Finalement, ce qui me plait le plus dans ce "C++ moderne", c'est le fait d'avoir des cycles de mise à jour plus courts ! Et de voir que le comité va (peut être ?) réussir à tenir le planning.
Avatar de Lynix Lynix
http://www.developpez.com
Membre habitué
le 17/05/2013 12:26
Très intéressant, mais j'espère qu'ils vont inclure quelque chose dans cette norme (Ou au pire dans le C++17): le static_if
Avatar de Klaim Klaim
http://www.developpez.com
Expert Confirmé
le 17/05/2013 12:29
Citation Envoyé par Lynix  Voir le message
Très intéressant, mais j'espère qu'ils vont inclure quelque chose dans cette norme (Ou au pire dans le C++17): le static_if

Nope, il a ete ecarte. Voir ce papier: http://isocpp.org/blog/2013/03/n3613...-if-considered

En gros, ils ont des arguments comme quoi ca marchera pas bien pour le C++ et sera meme dangereux. C'est partiellement discutable, mais ce document a ete suivi d'un rdv ou ils ont decide qu'ils feraient mieu de se concentrer sur les concepts d'abord et de peut etre reconsiderer plus tard, meme si ya peu de chances si quelqu'un les relance pas sur le sujet. Donc le sujet est clos au moins temporairement.
Avatar de koala01 koala01
http://www.developpez.com
Modérateur
le 17/05/2013 14:05
Salut,
Citation Envoyé par germinolegrand  Voir le message
Suivez-vous avec intérêt l'évolution du C++ ?

Avec beaucoup d'intérêt, comme sans doute toute personne qui préfère vraiment C++ aux autres langages mais qui apprécie d'avoir un langage "moderne"
Les ajouts votés vous paraissent-t-ils intéressants ?

Très

Citation Envoyé par Neckara  Voir le message
Bonjour,

Par contre je trouve qu'il manque des fonctionnalité plus "haut niveau" dans le C++ STL comme un std::plugin (manipuler/charger des plugins) ou une fonction permettant d'avoir la liste des serveurs DNS utilisés par l'ordinateur, accéder à des bases de données en renseignant le pilote à utiliser, etc.

Cela finira surement par arriver, patience
Heureusement boost (loué soit-il) permet déjà de compléter pas mal le C++

J'ai souvent tendance à considérer boost comme représentatif de ce que pourrait être C++, car il ajoute un tas de fonctionnalités portables et intéressantes.

L'énorme avantage de boost est, justement, qu'il s'agit d'un projet "personnel" (même si l'équipe est importante) et qu'il n'est pas soumis aux mêmes impératifs que la norme.

Il peut donc évoluer beaucoup plus vite que la norme
ne serait-ce que pour les sockets (std::socket n'existant pas encore à ma connaissance).

Les sockets, les threads sont de parfaits exemple de ce qu'une bibliothèque "tierce" peut faire beaucoup plus rapidement que la norme.

Il existe déjà certaines normes qui présentent les threads et les socket (comme la norme posix, il me semble), mais les systèmes qui ont décidé (à tord ou à raison) de ne pas la respecter n'ont, a priori, aucune raison de s'y contraindre.

S'il est *relativement* "facile" pour une bibliothèque tierce de décider d'une interface pour des threads ou des sockets qui permette la portabilité, la norme nécessite un certain corum quant à son acceptation et regroupe des décideurs ayant, parfois, des divergences importantes d'opinion.

Comme boost a, de plus, l'énorme avantage de disposer d'un très large publique, de nombreux utilisateurs, son utilisation est relativement "naturelle" dés qu'un besoin n'est pas satisfait par ce que propose la norme.

Les "us et coutumes" induits par boost deviennent donc assez rapidement une "norme de fait", et il est donc relativement "logique" que la norme se base fortement sur boost lorsqu'il s'agit de décider d'ajouter quelque chose au standard.

Seulement, la norme doit aussi apporter un formalisme beaucoup plus important que ce que n'importe quel bibliothèque tierce ne doit le faire, et c'est sans doute pour cela que l'intégration est susceptible de prendre du temps

Je pense donc que le C++ n'a pas encore fini de s'améliorer.

Je le pense aussi, et je l'espère de tout coeur
Avatar de Emmanuel Deloget Emmanuel Deloget
http://www.developpez.com
Expert Confirmé Sénior
le 17/05/2013 14:39
Citation Envoyé par Neckara  Voir le message
Bonjour,

On ne peut pas vraiment dire que je suis l'évolution du C++ pourtant c'est une chose que je trouve vraiment intéressante.

J'ai regardé vite fait, std::quote me semble assez pratique, std::optionnal nous permettra d'éviter de jouer avec les pointeurs quand on ne veut pas transmettre de valeurs, bref, il y a pas mal de petites choses^^

J'ai vraiment du mal à voir l'intérêt de std::optional, dans le sens où les alternatives (pointeur, valeur par défaut...) ne manquent pas - et qu'au niveau architectural, un std:optional n'a pas beaucoup de sens.

Je vais donc regarder ça d'un oeil nouveau, histoire de peser le pour et le contre.

Citation Envoyé par Neckara  Voir le message
Par contre je trouve qu'il manque des fonctionnalité plus "haut niveau" dans le C++ STL comme un std::plugin (manipuler/charger des plugins)

Ah... A la limite, un système de chargement déchargement de librairies dynamiques, je suis pour. Appeler ça std::plugin, ça reviendrait à imposer aux applications un système qui ne peut pas être générique (et n'est d'ailleurs pas souhaitable). Un plugin peut prendre différentes formes - code natif, code interprété... Bref : la fonctionnalité de base : oui ; un std::plugin: non.

Citation Envoyé par Neckara  Voir le message
ou une fonction permettant d'avoir la liste des serveurs DNS utilisés par l'ordinateur,

Pour autant que je me le rappelle, c'est en cours. Et la solution viendra à priori de la librairie asio.

Citation Envoyé par Neckara  Voir le message
accéder à des bases de données en renseignant le pilote à utiliser, etc.

A l'heure actuelle il n'existe aucun standard pour permettre l'accès aux base de données. Il y a autant de systèmes que d'OS et de DB différents. Si on rajoute à ça les différents types de SGBD (relationnel, objet, nosql...) on arrive à quelque chose qui, mon avis, n'est pas normalisable.

Ce qui peut être normalisé, par contre, c'est une extension du langage genre linq (voire une extension de la librairie qui fournit des services similaires). L'idée est de travailler sur des collections (i.e. des conteneurs). Il devrait être possible d'écrire :

Code :
1
2
3
4
5
6
 
from(collection1, collection 2).select([](const col1type::value_type&a, const col2type::value_type& b) { 
    return std::make_tuple(a.id, b.info1, b.info2); 
}).where([](const col1type::value_type&a, const col2type::value_type& b) { 
     return a.somevalue == b.othervalue; 
});
Ce code peut déjà être écrit en C++11. Une extension de ce type peut fournir l'essentiel des services qui sont généralement utilisés sur un SGBD. De plus, il peut être écrit de manière à spécialiser l'accès à un SGBD particulier (tout en continuant de fonctionner sur les conteneurs de la librairie standard).
Avatar de koala01 koala01
http://www.developpez.com
Modérateur
le 17/05/2013 15:27
Citation Envoyé par Emmanuel Deloget  Voir le message
J'ai vraiment du mal à voir l'intérêt de std::optional, dans le sens où les alternatives (pointeur, valeur par défaut...) ne manquent pas - et qu'au niveau architectural, un std:optional n'a pas beaucoup de sens.

Et pourtant, il me semble qu'il en est peut etre question pour "plus tard" (2017 )

Ceci dit, je ne suis pas particulièrement d'accord avec toi sur ce coup:

Les valeurs par défaut, c'est bien, mais cela implique de définir une valeur qui puisse être considérée comme "invalide" (est-ce -1 , std::numeric_limits<>::max() , autre chose ) et les pointeurs... Bah, on est tous conscients des problèmes qu'ils peuvent occasionner

Indépendamment de la manière dont std:: optionnal serait implémenté, le fait de pouvoir dire explicitement qu'une valeur peut ne pas exister et de pouvoir déterminer si elle existe ou non aurait de nombreux avantages.

Regardes "simplement" toutes les parties optionnelles que l'on peut retrouver dans la simple déclaration d'une fonction membre:
  1. accessibilité -->optionnel
  2. static | virtual --> optionnel
  3. type de retour --> requis
  4. constant | volatile -->optionnel
  5. pointeur | référence --> optionnel
  6. array -->optionnel
  7. nom -->requis
  8. parenthèse ouvrante -->requis
  9. liste d'arguments --> optionnel
  10. parenthèse fermante -->requis
  11. const qualifier -->optionnel
  12. end of statment -->requis
Sur douze éléments susceptibles d'apparaitre dans une "simple" déclaration de fonction, plus de la moitié sont des éléments optionnels, dont l'absence a une signification propre.

Le fait de pouvoir dire que quelque chose peut ne pas exister et de pouvoir donner une signification à cette non existence peut faciliter grandement la vie, et pas seulement au niveau des AST
Avatar de gbdivers gbdivers
http://www.developpez.com
Inactif
le 17/05/2013 15:35
On en avait parlé lors des traductions des articles sur les retours d'erreur, il me semble.
Pour moi, finalement ce n'est rien d'autre qu'un pair<bool, T> avec un sémantique adapté et sécurisé. C'est que l'on a par exemple avec map::find, qui retourne un pair<iterator, bool>.
Avatar de jmnicolas jmnicolas
http://www.developpez.com
Membre émérite
le 17/05/2013 15:58
<troll>
Vu qu'ils ont mis 8 ans pour sortir la précédente révision on peut estimer que C++14 s’appellera C++19, voir C++2x
</troll>
Offres d'emploi IT
Développeur php/mysql
Stage
OREVE TECHNOLOGIES - Ile de France - Paris (75000)
Parue le 31/08/2014
Développeur .net h/f
CDI
BULL FR - Midi Pyrénées - Toulouse (31000)
Parue le 20/08/2014
Analyste fonctionnel h/f
CDI
Atos Technology Services - Ile de France - Bezons (95870)
Parue le 18/08/2014

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

PlanetHoster
Ikoula