C++17 est maintenant officialisé

Les fonctionnalités intégrées au C++17 ont été décidées au cours du meeting à Oulu

Le comité autour du C++ s'est une nouvelle fois réuni afin de décider du contenu de la nouvelle version du langage de programmation C++.
Le comité a conclu une entente et la liste des fonctionnalités ne changera plus. Voici la liste des fonctionnalités qui intègreront C++17 :

• allocation dynamique de mémoire pour les données sur alignées : en effet, depuis C++11, vous pouviez spécifier l'alignement d'une structure avec alignas(). Toutefois, lors d'une allocation dynamique, il fallait vous-même gérer la taille de la mémoire alignée tout en prenant en compte, manuellement, l'alignement ;
• déduction des arguments de template pour les classes templates ;
• mot clé auto pour les templates : permet de définir le type utilisé dans un template au moment de l'instanciation du template ;
• garantie sur l'omission de la copie : notamment pour permettre à une fonction de renvoyer un objet impossible à déplacer (et aussi, de ne pas avoir à toujours définir le constructeur de copie et de déplacement lorsqu'ils ne sont pas du tout utilisés) ;
• une version affaiblie de l'ordre d'évaluation fixe pour les expressions : pour enlever toute ambiguïté sur un code tel que f(i++,i) ;
• contexpr if : condition traitée lors de la compilation ;
• garantie forward progress : amélioration de la formulation du standard ;
• variables inline ;
• liaisons structurées ;
• if et switch (regroupement de l'initiation et de la condition) : nouvelle syntaxe pour le mot clé if, permettant d'écrire if (status_code err = fct(); err != SUCCESS).

Du côté des fonctionnalités la bibliothèque standard, les quatre points suivants ont été acceptés :

• le C++17 repose sur C11 et non pas C98 ;
• variant<> : union avec protection du type ;
• destroy(_at|_n), uninitialized_move(_n), uninitialized_value_construct(_n), uninitialized_default_construct(_n) ;
• déplacement d'éléments pour map<>,unordered_map<>, set<>, and unordered_set<> ;
• réservation de std[0-9]+ pour les standards futurs.

Pour rappel, il y a trois mois (lors de la réunion précédente), le comité s'était accordé pour intégrer les fonctionnalités suivantes :

• attributs [[fallthrough]], [[nodiscard]], [[maybe_unused]] ;
• constexpr lambdas ;
• généralisation des boucles sur ensemble ;
• capture de *this dans les lambdas ;
• valeurs littérales hexadécimales pour les nombres à virgules flottantes ;

Et pour la bibliothèque standard :

• (parts of) Library Fundamentals TS v1 ;
• Parallelism TS v1 ;
• File System TS v1 ;
• fonctions mathématiques spéciales ;
• hardware_*_interference_size ;
• .is_always_lockfree() ;
• clamp() ;
• non-const .data() pour les chaînes de caractères.

Comme nous l'avions vu, les concepts ne feront pas partie du C++17. Vous pouvez voir la liste complète des fonctionnalités ici.
Évidemment, une nouvelle version du langage n'est rien si les compilateurs ne la supportent pas. On pourra donc se renseigner sur le progrès du support pour clang ici et pour libc++ ici.


Votre opinion

:fleche: Avez-vous suivi les évolutions du C++17 ? Qu'est-ce qui vous intéresse le plus dans les nouvelles fonctionnalités ?
:fleche: Envisagez-vous de l'intégrer dans vos projets au plus tôt ? Comment gérez-vous une transition ?


Source

Page IsoCPP sur les fonctionnalités du langage

Bonsoir c koi ca! j'avais decidé d'apprendre ce langage plutot que python.ca devient une horreur inutilisable.le developpement comme l'entretient deviennent quasi impossible seul.c'est 1 risque d'érreurs

majeur.les compilateurs et edi seront difficiles a mettre au point.cela va mettre en cause la portabilité des programmes. leurs financement aussi. on risque 1 fork à partir de c11. ils ont pondu 1 truc

indigeste, incomprehensible par la majorité des developpeurs. je mise sur python java modernisé et c sharp. merci ! je cours vite me laver les yeux de c17.

En même temps C++ à mon avis c'est pas destiné aux débutants et aux amateurs. Pour les amateurs débutants dans ton genre le Python c'est beaucoup plus simple en effet.

Moi qui voulais me remettre à programmer en C++, ayant appris avec les bon vieux standard comme les type float int double et les bonne vieille méthode de POO et de pointeur. J'ai voulu passer au C++ 11 et bien franchement je trouve que c'est de la vrai merde, tout est ambigue, les putins de mots clé comme auto, shared_ptr tout plein de mots clé barbare, pas moyen d'apprendre, de comprendre et d'exploiter c'est nouveau concepts à partir des bonnes vieilles bases du langage. Moi je suis tout perdu, je re-mets énormement en question mes connaissances sur le c++, bien franchement j'ai pas suivi son développement et je me suis encore moins préparé à l'arriver de ces nouvelles normes, si je m'avais pencher sur la bibliothèque boost j'en serais peut-etre pas rendu là, j'aurais été mieux préparé, mais bon il n'est jamais trop tard.

Les types de base , les (raw) pointer sont toujours là , que ce soit C++11 ou 17.
L'évolution apporte juste des simplifications qui au contraire évite les erreur très commune du C++.

Tu peux très bien faire un soft complet en c++11 sans utiliser auto si ca te convient pas.
De la même manière tu peux très bien choisir de faire des new/delete plutôt qu'un simple shared_ptr , faut juste pas oublier de désallouer :)

Citation:

---

Envoyé par grunk

De la même manière tu peux très bien choisir de faire des new/delete plutôt qu'un simple shared_ptr , faut juste pas oublier de désallouer :)

---

Au détail que c'est impossible (la faute aux exceptions) de garantir un libération de la mémoire sans encapsuler les ressources dans des capsules RAII. Et ça, depuis 98 (*), le seul truc qui change c'est que l'on n'a plus besoin d'une bibliothèque externe pour disposer d'un tel service.

De la lecture nécessaire pour une mise à jour rapide du truc le plus important par rapport à la pratique du C with classes: http://alexandre-laurent.developpez....ou-exceptions/

(*) enfin, on avait bien auto_ptr, et ses soucis comme vector<auto_ptr<>> qui ne marchait pas.

Citation:

---

Envoyé par therev123

des bonnes vieilles bases du langage

---

Justement, elles sont vieilles. Pourquoi continuer à utiliser des syntaxes complexes et potentiellement dangereuses (cf le message de Luc), s'il est possible de faire la même chose plus simplement et safe.

Les contraintes en termes de conception de logiciels ont évoluées, et les méthodologies de développement ont suivi. Soit il fallait changer de langage pour suivre ces nouveaux besoins, soit il fallait faire évoluer le C++. L'intérêt du C++ n'est pas de proposer une syntaxe vieille de 20 ans, mais de proposer les mêmes avantages qu'il y a 20 ans avec une syntaxe moderne. (Plus ou moins correctement, selon les compétences plus ou moins à jour des devs).

Et on est en 2016. Plus de 5 ans que le C++11 est normalisé. Cela fait un peu long pour se mettre à jour. Vous mettez plus de 5 ans pour apprendre un langage ?

Je ne comprend pas les commentaires précédents. Le C++ moderne a gagné en cohérence et en performance. Il y a des choses intéressantes aussi dans le C# par exemple, mais pour obtenir des perfs correctes on peut être amené à faire des bidouilles assez moches. Donc merci mais je reste en C++.

Si certaines évolutions sont louables comme la déduction des arguments templates pour les classes templates et constexpr if, d'autres me laissent dubitatifs. Par exemple, la levée de l'ambiguïté de f(i++, i); n'est, à mon sens, pas nécessaire: il suffisait d'écrire f(i, i); i++; ou f(i, i + 1); i++;, ce qui est nettement plus clair.

Citation:

---

Envoyé par grunk

Les types de base , les (raw) pointer sont toujours là , que ce soit C++11 ou 17.
L'évolution apporte juste des simplifications qui au contraire évite les erreur très commune du C++.

Tu peux très bien faire un soft complet en c++11 sans utiliser auto si ca te convient pas.
De la même manière tu peux très bien choisir de faire des new/delete plutôt qu'un simple shared_ptr , faut juste pas oublier de désallouer :)

---

Enfin quelqu'un qui comprend à la rejet du mot-clef auto et ma préférence pour l'utilisation des pointeurs nus par rapport à celles des pointeurs intelligents.

A noter que le code métier n'a pas à utiliser tous les systèmes plus complexes du C++.

Le but c'est de faire des librairies complexes avec beaucoup de possibilités mais qui rendent le code métier simple.

Franchement pour ceux qui utilisaient boost/le c++ moderne, il n'y a pas de gros changement avec C++11.

Pourquoi utiliser des pointeurs nus quand on sait qu'ils ne sont pas safe et que c'est si simple avec les pointeurs intélligents? (et bien sûr le fait qu'on doit utiliser les pointeurs en C++ que quand on en a vraiment besoin).

Citation:

---

Envoyé par mintho carmo

Et on est en 2016. Plus de 5 ans que le C++11 est normalisé. Cela fait un peu long pour se mettre à jour. Vous mettez plus de 5 ans pour apprendre un langage ?

---

Tu parles de langage. Hors, le C++1y est une surcouche/ amélioration/ [armure] du C++. Donc apprendre un langage, comme tu y vas :mrgreen:

De plus, vu comment le C++14 et le C++17 améliore/ déprécie/ change le C++11, je me dis que ceux qui ont appris le C++11 n'ont pas loupé le train, mais changent tous les 2 ans leurs acquis :aie: :aie: :aie:

À près on va, à coup sûr, me dire: les changements sont minimes, les changements ont été anticipés avec des bidouilles, les changements ne touchent qu'à la partie "faire une bibliothèque", les changements sont du sucre syntaxique ...

Ben vu que tu peux continuer à programmer de la même manière qu'avant, les changements restent minimes oui.

:ptdr: :ptdr: :ptdr: Tellement minimes que le C++11 remplace le C++98 comme norme par défaut.

Et donc? tes progs compilent plus?

Citation:

---

Envoyé par foetus

De plus, vu comment le C++14 et le C++17 améliore/ déprécie/ change le C++11, je me dis que ceux qui ont appris le C++11 n'ont pas loupé le train, mais changent tous les 2 ans leurs acquis :aie: :aie: :aie:

À près on va, à coup sûr, me dire: les changements sont minimes, les changements ont été anticipés avec des bidouilles, les changements ne touchent qu'à la partie "faire une bibliothèque", les changements sont du sucre syntaxique ...

---

Franchement, vu la lenteur du processus, comparé aux autres langages et frameworks, je suis plus dans le camp des "ça va pas assez vite" que le contraire.
Et oui, il faut toujours/régulièrement se mettre jour. A croire que le fait que le C++ n'ait pas évolué pendant 13 ans fut une force.

On vit une véritable accélération ...
Les compilateurs vont-ils suivre ?

Bjarne annonce qu'il y aura une volonté de simplification aussi bien à l'écriture qu'à l'enseignement du C++ tant mieux si c'est le cas.

L'avantage du C++ réside dans l'assurance que les codes doivent rester compatibles avec les premiers programmes en C++ des années 80 voir du C.

Donc, il n'y a pas de risques de peaufiner son C++11 déjà riche avant de se lancer sur du C++17 sûrement pas supporté par les compilateurs récents...

Et faudra-t-il déjà racheter une nouvelle version de compilateur ?

Citation:

---

Envoyé par GEP007

Bjarne annonce qu'il y aura une volonté de simplification aussi bien à l'écriture qu'à l'enseignement du C++ tant mieux si c'est le cas.

---

C'est déjà le cas avec C++11 et C++14.

Citation:

---

Envoyé par GEP007

L'avantage du C++ réside dans l'assurance que les codes doivent rester compatibles avec les premiers programmes en C++ des années 80 voir du C.

---

Avec le C++ et le C, normalisés, la compatibilité est globalement là et, malgré quelques différences, il est facile d'écrire du code compatible.

Citation:

---

Envoyé par GEP007

Donc, il n'y a pas de risques de peaufiner son C++11 déjà riche avant de se lancer sur du C++17 sûrement pas supporté par les compilateurs récents...

---

?
GCC et Clang supportent déjà une (bonne) partie de C++17 :
- https://gcc.gnu.org/projects/cxx-status.html#cxx1z
- http://clang.llvm.org/cxx_status.html#cxx17

Citation:

---

Envoyé par GEP007

Et faudra-t-il déjà racheter une nouvelle version de compilateur ?

---

GCC et Clang sont multiplateformes, libres, gratuits et open source.

Les gens qui se plaignent qu'il faut mettre à jour ses connaissances au fil des ans en informatique n'ont pas tout compris à leur métier :aie:

Citation:

---

Envoyé par jblecanard

Les gens qui se plaignent qu'il faut mettre à jour ses connaissances au fil des ans en informatique n'ont pas tout compris à leur métier :aie:

---

DITES CELA A BJARNE STROUSTRUP QUI OBLIGE UNE COMPTABILITÉ ASCENDANTE TOTALE

Pouvoir associer un programme écrit en archaïque C++14482-1985 sans aucune variable booléenne avec des composants C++C++14482-2011...
C'est cela l'informatique selon Bjarne STROUSTRUP, le reste est du commerce !

La pérennisation des programmes sans avoir à le récrire doit être le but ultime du programmeur Bjarne STROUSTRUP
Il ne faut pas confondre évolution ( garantie d'avenir ) et reconstruction dans une nouvelle variante ( preuve d'erreur ou de volonté commerciale )...

Les vraies questions sont :

Pourquoi devoir acheter un nouveau C++BUILDER ou un nouveau Visual Studio pour pouvoir intégrer C++11 puis maintenant devoir acheter un nouveau C++BUILDER ou un nouveau Visual Studio pour pouvoir intégrer C++17 ?

Les constructeurs vont-ils traîner la savate comme avec C++14482-2003 qui a mis des années pour être intégré dans les compilateurs ?

Et quel sera l'enjeux du C++17 MAJ ou Extension ?

Bjarne Stroustrup n'impose rien du tout, il est naturellement écouté au sujet de l'évolution de C++
mais il ne faut pas oublier que le C++ est un langage normalisé.
La compatibilité avec le C++ archaïque et le C (qui n'est pas stricte), a des avantages et des inconvénients
mais je suis convaincu que c'est l'une des raisons au succès du C++.

Généralement, les approches bibliothèques sont préférables à l'introduction de nouveaux mots clés ou nouvelles syntaxes.
Cependant, l'approche bibliothèque est limitée.
Les nouveaux mots clés et nouvelles syntaxes demandent plus de travail aux compilateurs,
il font donc de nouvelles versions.
GCC et Clang (voir liens de mon précédent message) implémentent (une partie de) la norme avant sa sortie officielle.
Visual Studio a beaucoup progressé "dans le bon sens" depuis C++11.
(Pour « C++BUILDER », je ne sais pas.)

GCC et Clang sont multiplateformes, libres, gratuits et open source.
Certaines versions de Visual Studio sont gratuites.

Il n'y a aucune vraie excuse pour ne pas mettre les compilateurs à jour (dans la grande majorité des cas).

C++17 demandera une mise à jour des compilateurs.
Entre les corrections de bugs, l'amélioration des temps de compilation, le développement de nouvelles techniques d'optimisation,
les compilateurs n'ont pas besoin d'une nouvelle norme du langage pour proposer des mises à jour.

Citation:

---

Envoyé par Ehonn

Bjarne Stroustrup n'impose rien du tout

---

Et si :

Voir les Cppcon ... Il est très insistant et clair là dessus !
Dans ces conférences, Bjarne Stroustrup insiste sur le fait que le C++ est le seul langage qui permet cela, c'est son ADN et son unicité, et aussi pour des raisons évidentes :
Exemples donnés :
On ne peut pas changer le plus grand système intelligent au monde ( téléphonie ) avec 40 heures de Downtime sur près de 40 ans, rapatrier un satellite ou étendre des capacité mémoire à des Mbal pour des MAJ purement commerciales...
Voir aussi les nombreux chapitres consacrés à cela dans le PPP 2nd et aussi The C++ Programming Language Fourth Edition Bjarne Stroustrup

Dans ses nombreuses interventions ( voir vidéos youtube ) Bjarne Stroustrup vante cette conservation de la compatibilité ascendante qui rend ce langage unique et qui, toujours selon lui, est primordiale, source de succès et source d'unicité de son langage mais aussi qui est la raison pour laquelle les normes ISOcpp 14482 sont passés de 65 pages à plus de ... 1353 pages... pour C++11.

Dernière référence et pas des moindres bien qu'en filigrane sur une partie du texte mais très insistant dans ses commentaires vidéos :
BJARNE STROUSTRUP : SOFTWARE FOR INFRASTRUCTURE une vraie anthologie en la matière !

Si tu travailles dans l'embedded cette motivation devient pas seulement évidente mais vitale au sens propre comme au sens figuré,
( Sans oublier la nécessité de travailler parfois plus efficacement en programmant directement en C pour les sockets Berkeley par exemple )

:arf:

Citation:

---

Envoyé par Ehonn

Il n'y a aucune vraie excuse pour ne pas mettre les compilateurs à jour (dans la grande majorité des cas)

---

Comme annoncé C++03 n'a pas fait mouche et n'a pratiquement pas été pris en compte par les fournisseurs de compilateurs professionnels :

Voir C++ Today The Beast Is Back
Gašper Ažman, Jon Kalbqui décrivent clairement ce refus de MAJ pour C++14482-2003 de la plupart des fournisseurs de compilateurs professionnels ...
Et Gašper Ažman, Jon Kalbqui se réjouissent ( et s'étonnent ) du changement de comportement et de la rapidité de 'réponse' des fournisseurs de compilateurs professionnels pour C++14482-2011.

:pc:

Citation:

---

Envoyé par GEP007

Dans ses nombreuses interventions ( voir vidéos youtube ) Bjarne Stroustrup vante cette conservation de la compatibilité ascendante qui rend ce langage unique et qui, toujours selon lui, est primordiale, source de succès et source d'unicité de son langage mais aussi qui est la raison pour laquelle les normes ISOcpp 14482 sont passés de 65 pages à plus de ... 1353 pages... pour C++11.

---

Et alors, quel est le problème (hormis un peu plus de travail pour les développeurs de compilateurs) ?
Par contre, que du code C++98 continue à fonctionner en C++14, c'est plutôt pratique.

Citation:

---

Envoyé par GEP007

Comme annoncé C++03 n'a pas fait mouche et n'a pratiquement pas été pris en compte par les fournisseurs de compilateurs professionnels :

---

La norme C++03 ne changeait pas grand chose à l'utilisation (https://web.archive.org/web/20160206...faq.html#C++03), contrairement aux normes C++11 et C++17, ce qui explique peut-être leur support précoce dans gcc et clang.

Citation:

---

Envoyé par GEP007

Pourquoi devoir acheter un nouveau C++BUILDER ou un nouveau Visual Studio pour pouvoir intégrer C++11 puis maintenant devoir acheter un nouveau C++BUILDER ou un nouveau Visual Studio pour pouvoir intégrer C++17 ?

---

Tu n'es pas obligé de le faire; mais tu peux lire l'article initial pour voir si ça vaut le coup pour toi.
Et sous-entendre que les normes C++ font marcher le commerce, c'est vraiment n'importe quoi : on en est à 5 normes en 30 ans (c'est à dire rien comparé au nombre de versions de java ou .net, en moins de temps) alors qu'il y a une nouvelle version de VS tous les 2 ou 3 ans pour changer la couleur des icones...

Citation:

---

Envoyé par GEP007

Et si :
Voir les Cppcon ... Il est très insistant et clair là dessus !

---

Ma réponse portait sur le mot « imposer » (imposer != insister).

Citation:

---

Envoyé par Ehonn

GCC et Clang sont multiplateformes, libres, gratuits et open source.

---

Pour quelle version de VS ? En tout cas pas VS2010 le plus utilisé professionnellement actuellement !

Citation:

---

Envoyé par Ehonn

Ma réponse portait sur les mot « imposer » (imposer != insister).

---

Hoooooo le politicien ? Jouerait-on sur le mots ? Pas grave tant que ce n'est pas le fameux léger mieux...:salut:

Dans mon petit laïus :

Insister <=> imposer <=> obliger <=> contrôler <=> sinon pas son aval et là ....
Ce serait une censure totale <=> absolue <=> échec majeur ( sauf pour les hobbyistes ) dans tout mon entourage professionnel mais aussi pour nombre de mes anciens collègues travaillent dans le domaine du Vital et de la sécurité.

Dans le milieu professionnel :

Insister <=> manière très polie et douce de nous annoncer avec un tendre sourire ( management oblige ) que nous avons deux options possibles : Oui ! ou Oui ! et parfois un choix multiple ... Nous permettant d'opter exceptionnellement pour Oui sans le ! c'est déjà une forme de liberté.

Le succès du C++ c'est sa rigueur et sa fiabilité garantie par BS... A ne pas négliger ! car les enjeux sont très grands

ILLUSTRATION : Pourquoi utilise-t-on Boost ?
Uniquement parce que Bjarne le trouve ok ... malgré une complexité reprochée qui a été sujet de grandes et nombreuses discutions pour les fault-finding..

What do you think of Boost?

Boost is a large and expanding collection of libraries designed to work well with the ISO C++ standard library. It contains many extremely useful and well-engineered libraries, such as asio, filesystem, regex, and thread (apologies for not trying to identify more useful libraries; there are just too many). One library, TR1, contains a good approximation of new C++11 standard library components.
The Boost libraries have tests suites, have documentation, have been tested on multiple systems, and are peer reviewed.

I have two problems with Boost, though, which I hope will be dealt with eventually:

It is too hard to download and use just one Boost library; the libraries seem overly coupled making it hard to pick and choose.
Some of the libraries are too clever for my taste. Sometimes, generality and simplicity coincide; in Boost, the balance is IMO too often so far towards generality that novices and average users are lost.
That said, it is usually a really dumb idea to go and reinvent a wheel that boost already offers.

http://www.stroustrup.com/bs_faq.html#boost
:scarymov:

Pour le support des normes C++ par Visual Studio : https://msdn.microsoft.com/fr-fr/library/hh567368.aspx
Et voici la version à priori gratuite : https://www.visualstudio.com/fr-fr/p...munity-vs.aspx

Je suis d'accord pour dire que Bjarne Stroustrup est très écouté dans le milieu (à juste titre) mais s'il dirigeait à lui seul les évolutions du langage,
on aurait les concepts et la surcharge de l'opérateur . en C++17.
C'est difficile de le faire passer pour le "dictateur" du C++.

Citation:

---

Envoyé par GEP007

DITES CELA A BJARNE STROUSTRUP QUI OBLIGE UNE COMPTABILITÉ ASCENDANTE TOTALE

---

M. Stroustrup est un des plus fervents défenseurs des nouvelles fonctionnalités du C++, essayer de prendre la compatibilité comme un argument pour la non évolution est quand même assez vide de sens. Que ça te plaise ou non, le langage évolue, les IDE aussi, les usages aussi. Donc même si tu estimes que ça devrait pas être le cas, c'est concrètement ce qui se passe, et si tu ne t'adaptes pas, ta valeur sur le marché du travail va chuter, et ce sera tant pis pour toi. Et c'est vrai dans tous les secteurs de l'informatique, C++ ou autre. Les développeurs qui vivent enfermés dans le passé et leur habitudes sont une vraie plaie pour les projets.

Il y a des bouts d'argumentaires qui ne me paraissent pas très clairs : quel objectif les arguments servent à démontrer/appuyer. Du coup, la conversation m'a paru un peu suréaliste par moment. Je tente de participer, en espérant ne pas être trop à côté de la plaque.

Citation:

---

Envoyé par GEP007

DITES CELA A BJARNE STROUSTRUP QUI OBLIGE UNE COMPTABILITÉ ASCENDANTE TOTALE

Pouvoir associer un programme écrit en archaïque C++14482-1985 sans aucune variable booléenne avec des composants C++C++14482-2011...
C'est cela l'informatique selon Bjarne STROUSTRUP, le reste est du commerce !

La pérennisation des programmes sans avoir à le récrire doit être le but ultime du programmeur Bjarne STROUSTRUP
Il ne faut pas confondre évolution ( garantie d'avenir ) et reconstruction dans une nouvelle variante ( preuve d'erreur ou de volonté commerciale )...

Les vraies questions sont :

Pourquoi devoir acheter un nouveau C++BUILDER ou un nouveau Visual Studio pour pouvoir intégrer C++11 puis maintenant devoir acheter un nouveau C++BUILDER ou un nouveau Visual Studio pour pouvoir intégrer C++17 ?

Les constructeurs vont-ils traîner la savate comme avec C++14482-2003 qui a mis des années pour être intégré dans les compilateurs ?

Et quel sera l'enjeux du C++17 MAJ ou Extension ?

---

Il y a plusieurs aspects.
- Oui, B.Strousturp, et bien d'autres au sein du comité de standardisation veulent une compatibilité ascendante maximale. Cela n'empêche pas quelques dépréciations à commencer par "auto" et l'export de template en C++11, mais aussi auto_ptr et d'autres choses encore avec le C++17.
- Et oui, comment l'ont dit d'autres : la compatibilité ascendante pour permettre la maintenabilité de vieux parcs informatiques/base de codes n'est pas antinomique avec l'évolution de la technologie derrière ces logiciels pour les prochains développements et même enseignements.

Comme il l'a été dit, B.Stroustrup, et bien d'autres, recommandent de passer à un C++ modernisé. Ils recommandaient aussi un C++ moderne sur la mouture 98 du langage avec du RAII dedans, mais ce n'est pas pour autant que notre industrie avait compris l'importance du message.

Après, je ne vois pas d'où sortent ces arguments de devoir acheter quoi que ce soit. Hormis quelques compilateurs tel que celui d'intel (fourni avec des Xeon phi où il est le plus pertinent), les 3 compilateurs majeurs : g++, VC++ et clang++ sont gratuits aujourd'hui. Microsoft a changé sa politique de distribution. Et franchement, le prix d'une licence de VC++ pro n'est pas insurmontable comparée au prix d'une machine de développement et de quantité d'autres COTS.
BC++B, je vois qu'il existe toujours mais en tant que surcouche avec ajouts à clang. C'est cool. Je ne pense pas pouvoir dire que le comité force à son achat. En revanche, comme CLion et quelques autres, c'est un IDE qui peut apporter des choses à ceux qui préfèrent les EDI à des outils de barbus tels que Vim (et oui, on peut développer professionnellement avec ce dernier type d'outil)

Citation:

---

Envoyé par GEP007

[...]
Dans ses nombreuses interventions ( voir vidéos youtube ) Bjarne Stroustrup vante cette conservation de la compatibilité ascendante qui rend ce langage unique et qui, toujours selon lui, est primordiale, source de succès et source d'unicité de son langage mais aussi qui est la raison pour laquelle les normes ISOcpp 14482 sont passés de 65 pages à plus de ... 1353 pages... pour C++11.

Comme annoncé C++03 n'a pas fait mouche et n'a pratiquement pas été pris en compte par les fournisseurs de compilateurs professionnels :

Voir C++ Today The Beast Is Back
Gašper Ažman, Jon Kalbqui décrivent clairement ce refus de MAJ pour C++14482-2003 de la plupart des fournisseurs de compilateurs professionnels ...
Et Gašper Ažman, Jon Kalbqui se réjouissent ( et s'étonnent ) du changement de comportement et de la rapidité de 'réponse' des fournisseurs de compilateurs professionnels pour C++14482-2011.

---

Le standard du premier C++ ISO a 776 pages. Bien plus que 65.

Quant au changement de politique, quand les fournisseurs professionnels voient le succès de g++ ou de clang++, on doit pouvoir dire qu'ils voient vite le besoin de se moderniser s'ils veulent continuer à vendre. Rajouter l'embauche de quelqu'un comme Sutter à un poste de responsabilité chez Microsoft, ça doit aider pour améliorer les choses. Si mes souvenirs sont bons, il est arrivé à l'époque du VC++7.1 qui marquait une rupture (dans le bon sens) par rapport à VC++6.

Citation:

---

Envoyé par Ehonn

Bjarne Stroustrup n'impose rien du tout, il est naturellement écouté au sujet de l'évolution de C++

---

Faux :
C'est ce qui fait la particularité du C++ et de Bjarne Stroustrup : Il ne s'agit pas de computer science à obsolescence rapide mais de Computer Engineering d'électrotechnique dont les composants réseau & embbeded datent et perdurent. Domaines si chers à Bjarne Stroustrup qui a avant tout la fibre d'un Ingénieur.

Si besoins était :

1) I’m a founding member of the ISO standards committee for C++ where I serve as the chair of the working group for language evolution.
Programming : principles and practice using C++ / Bjarne Stroustrup. — Second edition.
ISBN-13: 978-0-321-99278-9
ISBN-10: 0-321-99278-4
Third printing, June 2015

2) Suivre "l'implication active et parfois déroutante" de Bjarne Stroustrup C17++ le Safe Coding avec Microsoft

Cette argumentation me parait complètement décousue. Que Stroustrup soit le "chair" d'un groupe de travail ne lui permet pas d'imposer ce qu'il veut dans la norme, envers et contre tous. Au passage, Stroustrup a un doctorat et a beaucoup travaillé comme universitaire donc bon, il doit y avoir plus fibreux comme ingénieur... Quant à l'exemple des composants réseaux, je ne crois pas que le C++ y soit plus adapté que erlang, C ou java.

Enfin, concernant l'obsolescence rapide de la science face à la technique qui perdure, c'est juste un non-sens. Seule une technique peut devenir obsolète, par exemple suite à l'apparition d'une technique plus efficace. Une science concerne les connaissances; elles peuvent être complétées ou corrigées mais pas devenir obsolètes.

J'évite de trop répondre à ce fil de discussion qui part dans tous les sens de manière que je n'arrive pas à suivre. Je vais donc me limiter aux éléments factuels.

Bjarne n'est plus le "chair of evolution". Il a cédé sa place depuis quelque temps déjà à Ville Voutilainen pour se concentrer plus sur certaines propositions qui lui tiennent à cœur. Et il n'a pas plus de pouvoir que n'importe quel membre du comité, même s'il a plus d'influence que certains. La preuve en est que la plupart de ses dernières propositions ont été rejetées (ce que je trouve très dommage pour certaines).

Je n'ai rien compris à la remarque sur le safe coding (ça ressemble à une citation, mais de qui, dans quel contexte ?). Je sais que Bjarne a travaillé avec Microsoft et d'autres sur des moyens de rendre le C++ plus sûr en permettant en particulier à du dataflow intra-procédural d'apporter suffisamment d'informations pour être utile, en enrichissant la sémantique des paramètres des fonctions. Ça s'est traduit pour l'instant au niveau du langage par des propositions sur les span, qui ne sont pas encore acceptées je crois. Et en dehors du standard, par des règles de codage ainsi que par une bibliothèque de support pour ces règles (https://github.com/isocpp/CppCoreGui...eGuidelines.md et https://github.com/Microsoft/GSL). Mais c'est loin d'être le seul sujet sur lequel Microsoft et actif (tout comme les gens de gcc ou de clang, d'ailleurs, à eux 3, ils forment la majorité des participants actifs au standard).

Citation:

---

Envoyé par Luc Hermitte

Le standard du premier C++ ISO a 776 pages. Bien plus que 65.

---

Tu as tout à fait raison : 776 pages pour C++03 mais je parlais de C++1985 et ses 65 pages...

Citation:

---

Envoyé par JolyLoic

Je n'ai rien compris à la remarque sur le safe coding ça ressemble à une citation.

---

Etonnant :
Le safe coding est la partie révolutionaire de C++11, C++14 et C++17? ( On arrive à du Manage Coding sans utiliser C++/CLI et ses Handle )

Citation : Oui celle de ... Bjarne Stroutrup lui-même qui, dans ses nombreuses vidéos, donne l'exemple classique d'une condition entraînant un "return" avant la fin du statement qui contient l'instruction de destruction de l'objet...

Fini les mémoires non vidées avec le safe coding ! il annonce lui-même qu'il collabore avec Microsoft dans cet optique.

Si pour toi le "safe coding" est ce qu'on appel RAII/RFID/SBRM¹, cela existe depuis la toute première normalisation...
Note quand même que la première normalisation ISO date de 1998.

La partie révolutionnaire de C++11 est surtout la sémantique de déplacement intégré dans le langage.

¹ celle-là je la sors de cppreference :D

Le C++17 apportent de nombreuses nouveautés bienvenues. Il est vrai que le C++11 était un peu bancale sur certains points mais le C++14 est arrivé et a permis de les combler. Cela fait 1 an que je développe mes lib template avec C++17 (en mode béta), et je dois dire que ceux qui parlent de sucre syntaxique uniquement, n'y connaissent pas grand chose, car c'est bien plus que cela. Cette dernière version m'a par exemple permis de réécrire nombre de mes fonctions template avec le mot clé auto au lieu de la déclaration habituelle 'template<typename type1, ...>', alors que dans le corps de la fonction, les types ne sont pas utilisé. Et même quand c'est le cas, decltype est là pour nous sauver la vie :D

La spécification de la nouvelle version du langage C++ (C++17) est finalisée
À la dernière minute, le comité a ajouté le type std::byte.

Le comité de réflexion autour du langage C++ s'est rassemblé une nouvelle fois à Kona (États-Unis) afin de finaliser la nouvelle version du C++. Actuellement, toutes les fonctionnalités sont spécifiées, il ne reste plus que l'approbation à la norme ISO pour que le C++17 soit inscrit dans le marbre. Toutefois, ces derniers correctifs sont mineurs et nous pouvons donc déjà nous pencher sur la nouvelle version.

Au cours du rassemblement et avant la finalisation du langage, un nouveau type a été introduit : std::byte (P0298R3). Ce type a été conçu spécifiquement pour les accès bruts à la mémoire. Jusqu'à présent, les programmeurs utilisaient char ou encore unsigned char qui sont conçus pour représenter avant tout des caractères. En plus, il est possible d'appliquer des opérations arithmétiques sur les char, ce qui ne convient pas. Bref, un nouveau type, pour permettre un code plus clair et plus de sécurité sur les types.

En plus du nouveau type std::byte, le C++17 apporte, entre autres :

• de nouvelles règles de déduction de types pour le mot clé auto sur les listes d'initialisation (N3922) ;
• l'ajout de if dans les expressions pouvant être résolues à la compilation (P0128R1) ;
• la déduction des arguments de template pour les classes templates (P0091R3) ;
• l'utilisation du mot clé auto pour les templates (P0127R1) ;
• la garantie sur l'omission de la copie (P0135R0) ;
• if et switch peuvent procéder à une initialisation if (status_code err = fct(); err != SUCCESS) (P0305R0) ;
• la garantie forward progress (P0296R0) ;
• les variables inline (P0386R0) ;
• les liaisons structurées (« Structured Bindings ») (N4659) ;
• l'affaiblissement de l'ordre d'évaluation fixe pour les expressions : pour enlever toute ambiguïté sur un code tel que f(i++,i) (P0145R2) ;
• l'allocation dynamique de mémoire pour les données sur alignées (P0035R4) ;
• la permission d'imbriquer les espaces de nommage et les énumérations : namespace X::Y { ... } (N4230) ;
• la permission d'avoir des attributs pour les namespace et énumérations (N4266) ;
• l'ajout des trois attributs [[fallthrough]], [[nodiscard]] et [[maybe_unused]] (N4640) ;
• l’ajout du support des caractères littéraux au format Unicode 8 bits (u8) (N4287) ;
• la permission de ne pas mettre un message dans static_assert (N3928) ;
• le remplacement de std::uncaught_exception par std::uncaught_exceptions (N4259) ;
• l'ajout des types std::variant et std::any (N4659 et P0220R1) ;
• une interface pour les systèmes de fichiers (N3505) ;
• la parallélisation des algorithmes de la STL (P0024R2) ;
• les lambdas constexpr (P0170r1) ;
• la généralisation des boucles sur ensemble (P0184R0) ;
• expressions de réductions (« fold expressions ») (N4295) ;
• la capture de *this dans les lambdas (P0018R3) ;
• les valeurs littérales hexadécimales pour les nombres à virgule flottante (P0245R1) ;
• résolution d'un manque de précision sur les conversions de qualificatifs pour les pointeurs pointant sur des tableaux de pointeurs (N4261) ;
• ajout des spécifications d'exceptions au système de typage (P0012R1) ;
• ajout de __has_include permettant de demande au préprocesseur si un fichier d'entête est disponible (P006R1) ;
• suppression de l'opérateur ++ pour les booléens (P0002R1) ;
• la suppression des trigraphs (N4086) ;
• la suppression du mot-clé register (P0001R1) ;
• la suppression de std::auto_ptr et std::random_shuffle (N4190) ;
• ....

Évidemment, le comité continue son travail sur les fonctionnalités qui n'ont pas pu être intégrées dans C++17. Ainsi, on peut espérer les voir dans C++20 :

• les concepts ;
• les ranges ;
• les modules ;
• le réseau ;
• les coroutines ;
• la réflexion ;
• les graphismes 2D (dans la lignée de cairo).

Du côté des compilateurs, le support complet de C++17 devrait bientôt arriver. Par exemple, GCC7 est en phase de stabilisation et devrait donc être bientôt disponible. De même pour clang 5.


Votre opinion

:fleche: Avez-vous déjà commencé des développements avec C++17 ? Quelles nouvelles fonctionnalités utilisez-vous ?


Source

L'annonce de Herb Sutter
Les fonctionnalités de C++17

@LittleWhite: pas cool, de faire des poissons d'avril pareils :aie::aie::aie:

De C++14 à C++17, qu’est-ce qui a changé avec la nouvelle version du langage C++ ?
un document de la Standard C++ Foundation

Comme nous l’avons annoncé il y a quelques jours, la spécification de la nouvelle version du langage C++ (C++17) est désormais finalisée, attendant l'approbation à la norme ISO. Si la publication du prochain standard pour le langage C++ sera faite plus tard cette année, on connait déjà les changements qui ont été opérés par rapport à C++14, le standard actuel.

La Standard C++ Foundation, une organisation chargée de la promotion de standards C++, a donc publié un document qui énumère tous les changements importants introduits depuis la publication de C++14. Le document présente entre autres les fonctionnalités supprimées ou obsolètes, les nouvelles fonctionnalités de base du langage, les nouvelles bibliothèques et les modifications aux fonctionnalités existantes.

:fleche: Changements officiels de C++14 à C++17


Votre opinion

:fleche: Pensez-vous que le C++ moderne va dans la bonne direction ou pas ?
:fleche: Quelle version de C++ utilisez-vous actuellement pour vos développements ?

Une autre présentation, plus orientée exemples : https://github.com/tvaneerd/cpp17_in.../ALL_IN_ONE.md

Vraiment ces cool.
D'avoir ajouter certaines fonctionnalités sur ce Langage à Haute Gamme pour les développeurs.

Du 15 au 20 mai a eu lieu la BoostCon intitulée « C++Now 2017 » dans laquelle on peut citer :

https://www.youtube.com/watch?v=LvwXJjRQfHk
C++Now 2017: “C++17 Features” par Bryce Lelbach

qui présente de nombreuses nouveautés du langage et de la bibliothèque standard introduites par la norme C++17, ainsi que :

https://www.youtube.com/watch?v=AqDsso3S5fg
C++Now 2017: “(Ab)using C++17” par Jason Turner

qui montre des exemples d'application.

Retrouvez :

:fleche: toutes les autres présentations sur la chaîne YouTube BoostCon ;
:fleche: les slides rattachés sur GitHub ;
:fleche: la chaîne YouTube de Jason Turner qui publie chaque semaine une courte présentation d'une fonctionnalité (nouvelle ou méconnue) du C++.