Comment écrire du bon code en C++14 ? Bjarne Stroustrup, le concepteur de C++ tente de répondre à la question

Comment écrire du bon code C++14 ?
Bjarne Stroustrup, le concepteur de C++ tente de répondre à la question

Lors de la conférence CppCon édition 2015, Bjarne Stroustrup, concepteur du langage C++, a tenté de répondre à la question que beaucoup de développeurs se posent : quels sont les critères pour écrire un bon code C++ moderne ? Par C++ moderne, il faut comprendre qu'il s'agit des versions C++11, C++14 et C++17 (en préparation).

Dans la vidéo ci-dessous, Bjarne Stroustrup a donné son point de vue sur ce que c'est que le code moderne C++. Il a commencé par les possibilités qu'offrent les nouveaux standards C++ dont la simplicité et la facilité qu'ils offrent pour coder, la rapidité d'exécution des programmes puis les mauvaises pratiques auxquelles les développeurs ont recours au moment de coder par exemple l'utilisation du C++ dans des styles archaïques ou correspondants à d'autres langages. En bref, le père du C++ a tenté de convaincre que les nouveaux standards C++(11, 14, 17) permettent d'écrire du code simple et rapide tout en offrant de bonnes performances avec une portabilité multiplateforme. Si selon lui, tous les versions C++1* sont d' « excellents langages modernes », C++14 meilleur que son prédécesseur C++11. Cependant, il espère que C++17, qui n'est pas encore prêt, soit encore beaucoup mieux que C++14.

Il n'a pas manqué de parler de son projet C++ Core Guidelines qui a pour objectif d'apprendre aux développeurs à écrire de bons codes C++ moderne. Il en a profité pour donner des conseils sur de bonnes pratiques pour écrire du bon code en C++ moderne avec des exemples tels que la bonne gestion des « pointeurs fantômes ».

https://www.youtube.com/watch?v=1OEu9C51K2A

Et vous ?
:fleche: Avez-vous regardé la vidéo ? Que pensez-vous des avis de Bjarne Stroustrup ?
:fleche: Codez-vous en C++ moderne ? Quelle version ?
:fleche: Que pouvez-vous dire des améliorations apportées en C++ moderne ?
:fleche: Partagez-vous les mêmes avis que Bjarne à propos des bonnes pratiques et des mauvaises à éviter ? Pourquoi ?

Source : Writing Good C++14

Voir aussi :
:fleche: Cours C++
:fleche: Forum C++

J'ai regardez succinctement (feuille par feuille), ces biens du C++ Moderne.
Je ne code pas, pas d'activité relié à cela pour l'instant.
J'ai utilisé le C++ comme support pour facilité l'intégration de modèle orienté objet, sinon faire la même chose en C est un peu plus fouillis. (étude qui date d'il y a longtemps)
Mon avis est que le C++ à fini par devenir une parti similaire au système exploitation en matière d'interruption applicative, mais une application qui plante peut elle signaler sans "try catch" valide puisqu'elle a planté? (débogage aussi malheureusement)
Je crois bien que C++ Moderne ressemble de plus en plus à JAVA (try() catch du main()), voir même indissociable, mais cela n'engage que mon opinion.

:fleche: Avez-vous regardé la vidéo ? Que pensez-vous des avis de Bjarne Stroustrup ?
Oui, j'ai regardé la vidéo (elle ne date pas d'aujourd'hui). Stroustrup parle de manière logique, je ne vois pas comment on peut "contredire" ce Monsieur. Cependant il dit qu'il/on n'aime pas les règles imposées, parfois ces "règles" peuvent assurer la cohérence. Je pense aux conventions de nommage par exemple, en C++ il n'y a rien d'officiel, dans d'autres langages, à commencer par Java il y en a, et ces langages où il y a des règles ont une très forte communauté. Donc il faut des règles bien conçu en amont pour ne pas avoir à en souffrir plus tard.

:fleche: Codez-vous en C++ moderne ? Quelle version ?
Oui, je précise le flag de C++14 pour bénéficier des nouveautés du langage (surtout les lambdas là où il en faut), mais si je le fais c'est déjà parce que je le fais au niveau perso. Je n'imagine même pas à quelle version du compilateur les entreprises sont bloquées (j'imagine un truc vieux comme le monde, genre C89 ou C03 pour certains).

:fleche: Que pouvez-vous dire des améliorations apportées en C++ moderne ?
C'est bien... mais comment dire...

1. Cela complexifie toujours un peu plus le langage, qui est déjà sémantiquement tellement complexe qu'aucun IDE C++ n'arrive à gérer toutes les erreurs pré-compilation.
2. Pourquoi s'attardent t-ils sur une tonne de truc pas forcément très utiles alors qu'ils pourraient concentrer leurs efforts sur les choses les plus demandés ? Je pense par exemple aux modules...
3. Le C++ n'est t-il pas un langage proche de la machine ? Pourquoi n'est t-il toujours pas possible de naviguer de dossier en dossier ? Ou utiliser les sockets de manière standard ne serait-ce que pour échanger des octets d'une machine à l'autre ? Si des langages de plus haut niveau peuvent assurer ces fonctionnalités bas niveau de manière interopérable (ex: Java, Python etc), c'est qu'il y a un problème au niveau du groupe de standardisation.
4. Pourquoi la STL "offre" des API toujours plus complexe ? Je vous donne un exemple standard un peu WTF pour récupérer le timestamp dans un type entier (cadeau :D ) :
   
   Code:

   ---

   1 2 3

   int64_t nbMillis = duration_cast<std::chrono::milliseconds>( system_clock::now().time_since_epoch() ).count();

   ---

   Là ça confirme un peu plus pour moi qu'il y a un problème au niveau du groupe de standardisation...
5. Il y a aussi des trucs persos que je ne comprend pas, comme par exemple le fait d'être obligé d'écrire un attribut static 2 fois pour la déclaration (une fois dans le header, et l'autre obligatoirement dans le fichier d'implémentation... alors que celle du header devrait suffire).

:fleche: Partagez-vous les mêmes avis que Bjarne à propos des bonnes pratiques et des mauvaises à éviter ? Pourquoi ?
Pas forcément, parce que tous les ajouts, notamment sur les pointeurs intelligent ou rvalue reference && (aussi bien soient-ils) :

1. Complexifient le langage
2. Ne seront pas utilisés parce que certains frameworks comme Qt ont leurs propres conventions d'écriture (vous voyez pourquoi c'est important les conventions...)
3. Nécessitent un temps de formation non négligeable
4. Et le pire : Ne seront pas respecté par tout le monde tout simplement (ceux qui n'ont pas le bon IDE/compilateur, les débutants, ceux qui vivent dans leur grotte, ceux qui se prennent pour le Dieu du dév etc).

PS: S'il vous plait, ne me dite pas qu'il y a Boost pour combler certains manques du langage.

• Avez-vous regardé la vidéo ? Que pensez-vous des avis de Bjarne Stroustrup ?

oui 90% mais pas tout ,
je suis plutôt d’accord avec Bjarne Stroustrup sur la sécurisation, simplification du langage et je reste toujours convaincu que le gros avantage du c++ c'est son orthogonalité (pouvoir faire du bas niveau et/ou de la très haut abstraction)

• Codez-vous en C++ moderne ? Quelle version ?

oui c++11 avec clang

• Que pouvez-vous dire des améliorations apportées en C++ moderne ?

pour c++ 11 la notion de owner (unique_ptr,weak_ptr) mais aussi la possibilité de simplifier son code ex parcourir un conteneur facilement avec for : for(auto & OneChar : oneString) rien que cette exemple simplifie et sécurise le code.

• Partagez-vous les mêmes avis que Bjarne à propos des bonnes pratiques et des mauvaises à éviter ? Pourquoi ?

oui même si ce n'est pas toujours facile à mettre en place quand on récupère un projet (temps et moyen) mais rien que le fait de simplifier son code avec des fonction standard sécurise sont code et corrige d'éventuelle bug qui serais passer inaperçu j'ai eu le cas su un projet sur laquelle j'ai travaillé le code daté des année 90 j'ai dû le migré en 64bit rien que le fait de factoriser le code en utilisent des pointeur intelligent à corriger des bug et a améliorais la performance.

Citation:

---

Envoyé par Gugelhupf

Ne seront pas respecté par tout le monde tout simplement (ceux qui n'ont pas le bon IDE/compilateur, les débutants, ceux qui vivent dans leur grotte, ceux qui se prennent pour le Dieu du dév etc).

---

Comme on dit tous les chemins mènes à Rome.

Citation:

---

Envoyé par MikeRowSoft

Mon avis est que le C++ à fini par devenir une parti similaire au système exploitation en matière d'interruption applicative, mais une application qui plante peut elle signaler sans "try catch" valide puisqu'elle a planté? (débogage aussi malheureusement)
Je crois bien que C++ Moderne ressemble de plus en plus à JAVA (try() catch du main()), voir même indissociable, mais cela n'engage que mon opinion.

---

Les try-catch sont une nuisance pour le débugguage. Avec un bon core-dump, franchement, on fait du bien meilleur boulot.
Ressemble à Java ? Non. Mais qui entérine le "il n'y a pas besoin de surveiller tous les chemins pour libérer les ressources", à la limite. Et encore, depuis 98 on a quasi tout ce qu'il faut dans le langage. Et avec le C++17, on aura encore bien mieux. Cf la présentation d'A Alexandrescu aux CppCon 2015 toujours.
Mais il est vrai, que contrairement à Java, il n'est pas dans les mentalités de penser qu'il ne faut surtout pas chercher à libérer la mémoire à la main.

Citation:

---

Envoyé par Gugelhupf

a- Je pense aux conventions de nommage par exemple, en C++ il n'y a rien d'officiel, dans d'autres langages, à commencer par Java il y en a, et ces langages où il y a des règles ont une très forte communauté. Donc il faut des règles bien conçu en amont pour ne pas avoir à en souffrir plus tard.

:fleche: Que pouvez-vous dire des améliorations apportées en C++ moderne ?
C'est bien... mais comment dire...

1. b- Pourquoi s'attardent t-ils sur une tonne de truc pas forcément très utiles alors qu'ils pourraient concentrer leurs efforts sur les choses les plus demandés ? Je pense par exemple aux modules...
2. c- Il y a aussi des trucs persos que je ne comprend pas, comme par exemple le fait d'être obligé d'écrire un attribut static 2 fois pour la déclaration (une fois dans le header, et l'autre obligatoirement dans le fichier d'implémentation... alors que celle du header devrait suffire).

:fleche: Partagez-vous les mêmes avis que Bjarne à propos des bonnes pratiques et des mauvaises à éviter ? Pourquoi ?
Pas forcément, parce que tous les ajouts, notamment sur les pointeurs intelligent ou rvalue reference && (aussi bien soient-ils) :

1. d- Complexifient le langage
2. e- Ne seront pas utilisés parce que certains frameworks comme Qt ont leurs propres conventions d'écriture (vous voyez pourquoi c'est important les conventions...)
3. f- Nécessitent un temps de formation non négligeable
4. g- Et le pire : Ne seront pas respecté par tout le monde tout simplement (ceux qui n'ont pas le bon IDE/compilateur, les débutants, ceux qui vivent dans leur grotte, ceux qui se prennent pour le Dieu du dév etc).

PS: S'il vous plait, ne me dite pas qu'il y a Boost pour combler certains manques du langage.

---

a- C'est surtout pour dire qu'il faudrait que les guides qualité arrêtent de se focaliser sur des choses qui ne participent pas à la robustesse des codes. Les règles proposées sur le github sont pratiquement toutes orientées robustesse.
Après, ce n'est pas à eux de pondre 20-50 pages de "un code cela doit ressembler à ça". Ce n'est franchement pas pertinent. D'autant qu'il y aura toujours des projets (d') "originaux" qui feront comme il leur plait.

b- Si c'est indirectement demandé par les équipes qualités des boites et des clients. Beaucoup veulent du "règles vérifiables par outils", et tant pis si RAII, SOLID et cie ne sont pas dans le guide qualité vu que l'on ne peut pas automatiser la vérification avec les outils pour lesquels on a payé des licences.

Les modules, c'est un truc attendu par les développeurs. Et ce n'est pas mis de côté. Cf la présentation de Gaby Dos Reis, et les papiers poussés au dernier meeting qui vient de se tenir.
Note que les modules ne sont étudiés que dans le cadre du C++ et non du C à ma connaissance.

c- Cf le papier pour le C++17: déclarations de variables inline

d- Guère plus que toutes les règles qui interdisent des choses à tour de bras

e- Rien n'empêche aux frameworks de prendre ce qui les fera progresser

f- Potentiellement vite amorti en quantité de bugs en moins au final.

g- Exactement comme les bonnes pratiques...

----

Sinon ... Il y a déjà eu une annonce :p
http://www.developpez.net/forums/d15...re-guidelines/

J'ai ajouté le lien de l'annonce du C++ Core Guidlines dans le premier message.

Citation:

---

Envoyé par Luc Hermitte

Mais il est vrai, que contrairement à Java, il n'est pas dans les mentalités de penser qu'il ne faut surtout pas chercher à libérer la mémoire à la main.

---

:arf:
Meurtre par abus de négation. Appelez la police !

Citation:

---

Envoyé par Luc Hermitte

Les try-catch sont une nuisance pour le débugguage. Avec un bon core-dump, franchement, on fait du bien meilleur boulot.
Ressemble à Java ? Non. Mais qui entérine le "il n'y a pas besoin de surveiller tous les chemins pour libérer les ressources", à la limite. Et encore, depuis 98 on a quasi tout ce qu'il faut dans le langage. Et avec le C++17, on aura encore bien mieux. Cf la présentation d'A Alexandrescu aux CppCon 2015 toujours.
Mais il est vrai, que contrairement à Java, il n'est pas dans les mentalités de penser qu'il ne faut surtout pas chercher à libérer la mémoire à la main.

---

T'en fait pas, le jour où des organismes ou entreprises de sécurités logiciels donneront des certifications sans courir après les failles (fini de donner une certification le temps d'un temps mort entre deux virus ou vulnérabilités) tu comprendra mieux mon opinion. Aussi bien toi que les autres, puisque jusqu’à maintenant personne n'en veux.

Citation:

---

Envoyé par Luc Hermitte

a- Après, ce n'est pas à eux de pondre 20-50 pages de "un code cela doit ressembler à ça". Ce n'est franchement pas pertinent. D'autant qu'il y aura toujours des projets (d') "originaux" qui feront comme il leur plait.

d- Guère plus que toutes les règles qui interdisent des choses à tour de bras

---

a. Si aujourd'hui tu proposes de partager un beau projet Java ou C# avec tes propres conventions d'écritures soit sur que tout le monde va dire que c'est mal codé (dont Sonar) et personne ne cherchera à forker ton projet. Avoir des conventions d'écriture c'est assurer la cohérence dans l'esprit du développeur et améliorer la maintenance du projet pour ceux qui prennent la relève.

d. Je prend un concept qui constitue la base du langage : le comportement des entités que l'on passe à travers un paramètre de fonction.

1. Java (2 cas) : Copie pour les types scalaires, et copie de référence pour les objets (dont tableaux qui sont des objets).
2. C# (4 cas) : Copie pour les types scalaires, passage par référence de type out ou ref (2 cas ici), et copie de référence pour les objets (dont tableaux qui sont des objets).
3. C++ (10 cas) : par défaut copie de valeur pour tous SAUF pour les tableaux qui passent par référence (2 cas ici), copie de référence pour les pointeurs, passage par référence SAUF le cas où on écrit par exemple un entier en dure et donc obligation de préciser le mot-clé const (2 cas ici), les rvalue reference SACHANT QUE ce dernier a priorité sur un passage par référence constant lors d'une surcharge de fonction (2 cas ici), les pointeurs intelligents divisés en plusieurs catégories (pointeur unique, partagé, et weak pour éviter les références circulaires)... et j'en oublie surement d'autres... mais en gros à vue d'oeil j'ai l'impression que nous sommes passé de 5 cas à 10 cas différents d'un coup... c'est beaucoup pour un concept constituant la base du langage, et tous ces cas particuliers du C++ font que le langage est toujours plus complexe.

Rien compris à cette catégorisation des paramètres, je n'en voit que 4:
- valeur
- rvalue
- référence
Et celui qui fait tache:
- pointeur pour les tableaux

S'il fallait ajouter un autre point: les rvalue template qui peuvent être soit des rvalue, soit des référence.

On est bien loin de 10 cas, je ne vois pas pourquoi pointeurs intelligents sont à prendre en compte dans cette catégorisation, se sont des classes comme les autres avec les mêmes comportements: copiable, déplaçable ou aucun des 2.

Citation:

---

Envoyé par MikeRowSoft

T'en fait pas, le jour où des organismes ou entreprises de sécurités logiciels donneront des certifications sans courir après les failles (fini de donner une certification le temps d'un temps mort entre deux virus ou vulnérabilités) tu comprendra mieux mon opinion. Aussi bien toi que les autres, puisque jusqu’à maintenant personne n'en veux.

---

Il est possible que je n'avais pas compris ton opinion. Ma lecture c'était que tu promouvais la programmation défensive. Et ... il y a tellement mieux. cf les 3 derniers billets de mon blog sur la PpC, et les discussions qui se tiennent à ce sujet pour le C++17.

@Gugelhupf
a- personne ne dit qu'il ne faut pas en avoir. Il faut en avoir. Mais ce n'est pas à un organisme international de les imposer, sinon d'autres seraient en non-conformité, Qt les premiers vu qu'ils ne respectent pas les conventions du standard. Dans tous les cas cela reste moins important que d'avoir un code robuste. Rien qu'avec un coup d'Astyle/uncrustigy/clang-format on corrige un grande partie du problème d'incohérences quand il y en a.

b- Non, Il n'y a qu'une façon en Java: le tout par valeur. C'est juste que ce sont les références qui sont passées par valeur. D'où que l'on ne peut pas faire de swap entre 2 références.

Pour le C++ le développeur lambda n'a toujours que 2 cas à retenir: la copie et la référence. Eventuellement la référence constante. Le reste, c'est pour les développeurs de bibliothèques. D'ailleurs, l'idée des CppCoreGuidelines, c'est d'interdire l'utilisation des pointeurs bruts qui sont des tableaux en decay (la traduction m'échappe), et ainsi de suite. Ce qui veut dire moins de cas dangereux à gérer. Certes cela rajoute plein de possibilités, mais on y gagne au final.
Ce sont des nouveaux types (non opaques :() à sémantique forte. Ce n'est pas comme si on demandait au compilateur de faire la différence entre des lignes et des colonnes, mais à un outil d'analyse de code de vérifier que l'on ne se plante pas.

Vous ne voyez pas autant de cas que moi parce que vous ne prenez compte que des modes de passage, je n'omet pas le type de l'entité utilisé et je prend en compte les cas particuliers (cf: la priorité des rvalues, le const obligatoire pour les valeurs précisées en dure etc).
Par exemple lorsque vous dite "valeur", un pointeur unique ne pourra pas passer par valeur parce que la copie est interdite, en gros on a là un nouveau "type d'entité" (ps : je parle bien de unique_ptr) qui va encapsuler notre objet et apporter de nouvelles règles particulières au langage qu'on devra connaitre, il ne s'agit là que d'un cas que je cite, mais il y a plein de choses comme cela à connaitre, d'où la complexité.

Le C++ propose effectivement beaucoup de fonctionnalités mais tu n'es pas obligé de toutes les connaitre pour utiliser efficacement le langage. Le principe de passage de paramètre par copie/référence suffit à la plupart du code qu'on écrit au quotidien et c'est même plutôt propre si on utilise aussi les std::array et std::vector.

Concernant le unique_ptr, je vois çà comme une fonctionnalité de la bibliothèque standard donc il est normal d'aller voir la doc pour l'utiliser. Et je ne suis pas sûr que la bibliothèque standard de Java soit beaucoup plus simple (bon ok, là c'est un peu de la mauvaise foi...).

Citation:

---

Vous ne voyez pas autant de cas que moi parce que vous ne prenez compte que des modes de passage, je n'omet pas le type de l'entité utilisé et je prend en compte les cas particuliers (
(a) cf: la priorité des rvalues,
(b)le const obligatoire pour les valeurs précisées en dure etc).

---

(a) Le cas particulier n'existe pas ici. Si une rvalue est "prioritaire", c'est parce que le type est une rvalue, sinon cela est une référence. Le compilateur choisi la fonction la plus proche selon les types entrées.
(b) Les littéraux ? Je serais étonné que C# supporte les références out sur littéral. Mais au niveau de l'appelant il n'y a que 2 types: rvalue (littéraux ou valeur temporaire, cast explicite) et les références.

Citation:

---

Par exemple lorsque vous dite "valeur", un pointeur unique ne pourra pas passer par valeur parce que la copie est interdite, en gros on a là un nouveau "type d'entité" (ps : je parle bien de unique_ptr).

---

Passage par valeur ne veut pas forcement dire copie. Les unique_ptr en valeur ça se fait, c'est la notion de déplacement. Le seul truc ajouté de puis c++11, c'est une représentation pour les rvalue dans les paramètres et std::move caster en rvalue au niveau de l'appelant.

appelant -> appelé
T&& -> T, T&&, T const&
T& -> T, T&, T const&

À cela, on enlève T si la classe ne le permet pas les déplacements et les copies.

Gugelhupf, j'ai l'impression que tu t'énerves tout seul parce que tu compares C++ à des langages qui ne sont pas comparables ;)

Tout d'abord, Java ou Python ne sont pas des standards internationaux. Donc ce sont des mauvais exemples pour donner les leçons au comité C++. Et puis d'ailleurs, Python 3 est loin d'avoir fait l'unanimité à sa sortie au point d'avoir douté si cette version du langage était une erreur. En comparaison, l'adoption de C++11 par l'industrie a été extrêmement rapide. Et on a eu les lambdas bien avant Java, comme quoi chez Python / Java les choses ne sont pas roses non plus ! :)

Ensuite, le comité C++ c'est pas comme une assemblée de politiciens que l'on paye de notre poche pour rendre notre vie meilleure. Ce sont des personnes / entreprises qui payent elles-mêmes non seulement leurs frais de participation mais aussi leur droit de vote si c'est le cas. Par exemple chez nous, pour que l'AFNOR dise "ok c'est bon tu peux défendre les intérêts de la France" tu dois lui payer chaque année plusieurs milliers d'euros. Donc quand une boîte investit pendant des années pour ajouter une fonctionnalité à C++, elle a en général une bonne raison de le faire. Et il vaut mieux pour elle, car elle doit en convaincre des dizaines d'autres d'accepter sa proposition. C'est la raison pour laquelle beaucoup de propositions sont rejetées : parce qu'il faut une sérieuse argumentation pour que ça passe.

Il faut donc faire preuve de prudence avec les termes tels que "les choses les plus demandées", ou encore "pas très utile", parce qu'une des premières choses qu'on apprend quand on fréquente le comité c'est qu'il y a beaucoup d'utilisateurs du langage qui ont des usages très différents des nôtres, et que par conséquent les termes "utile" ou "évident" sont à proscrire. Par exemple, il y a des personnes pour qui les modules relèvent du "nice to have" parce qu'ils savent très bien vivre sans depuis longtemps et que leurs priorités sont ailleurs.

Enfin, il faut comprendre le segment sur lequel C++ se positionne. Ce n'est pas un langage "clé en main" du style boite de LEGO prête à l'emploi. Visual Basic faisait très bien cela. C'est fou combien un programmeur VB était plus productif qu'un programmeur C++. Et pourtant, VB [d'avant .Net] a disparu ! C++ est un langage qui permet de construire soit-même ses propres briques en fonction de ses besoins. Car un développeur embarqué n'a pas les mêmes contraintes qu'un développeur de jeux vidéo ou un autre HPC. C++ vise à fournir le maximum d'outils utiles à tous ces différents profils pour qu'ils puissent créer la plateforme logicielle qui convient le mieux à leur contexte.

Du coup, on obtient une boite à outils très large. Et ce n'est pas parce que la caisse à outil contient beaucoup d'outils que je dois tous les utiliser. B. Stroustrup exprime très bien cela dans les premières minutes de la vidéo : "quand je me tape sur la tête avec un marteau ça fait mal !". A quoi ça rime de dresser la liste de toutes les combinaisons possibles de passage de paramètre ? ;) Les principes stipulés dans les core guidelines sont simples à ce propos.

Citation:

---

[*]Pourquoi la STL "offre" des API toujours plus complexe ? Je vous donne un exemple standard un peu WTF pour récupérer le timestamp dans un type entier (cadeau :D ) :

Code:

---

1 2 3

int64_t nbMillis = duration_cast<std::chrono::milliseconds>( system_clock::now().time_since_epoch() ).count();

---

---

Tu es *peut-être* trop orienté bas niveau. As-tu absolument besoin de manipuler des int64 ? Car la lib met à ta disposition des abstractions pour te simplifier la gestion du temps :

Code:

---

1 2 3 4 5 6

int64_t nbMillis = getTimestampFromExternalCode(); auto timestamp = chrono::milliseconds{nbMillis}; // sécurisé contre les comparaisons accidentelles avec d'autres unités de temps   if (timestamp > system_clock::now().time_since_epoch()) { // oops! }

---

c'est sûr que si on est habitué à tout gérer à la main soit-même, ça déstabilise. Mais si on comprend que la lib s'occupe d'abstraire pour nous certains concepts, alors ça devient autre chose. Combiné aux littéraux utilisateurs, ça devient même assez sexy:

Code:

---

1 2 3 4 5

chrono::milliseconds getTimestamp() { return 1500ms; }   if (getTimestamp() > 1s) { // expiré }

---

Bonsoir Aurelien.Regat-Barrel, ah non non c'est peut-être une impression mais je ne m'énerve pas du tout, ce sont juste mes constatations concernant le langage.

Java et Python (que je n'ai pas cité) ne sont peut-être pas des standard ISO/ANSI/ECMA mais ce sont des langages suffisamment efficaces et très utilisés pour être cité. D'ailleurs ces langages ne sont pas des mauvais exemples parce que chacune des nouveautés du C++ est directement inspiré de ces langages (final, override, initialize_list, lambda et j'en passe). Python3 a peut-être prit un risque mais cela en devait surement valoir la peine (il faut juste que le gouffre ne soit pas du même niveau pour Python4), contre exemple Java est rétro-compatible entre les différentes versions majeures. Enfin pour ce qui est de l'adoption très rapide du C++11 dans l'industrie j'ai un très gros doute mais c'est une impression personnelle.

Le fait qu'un langage ou protocole soit standardisé ne signifie pas forcément que c'est bien. Je prend l'exemple du SQL, il y a des gens qui n'aiment pas le SQL, moi je l'aime beaucoup et je pense que ceux qui le standardise prennent leur temps mais font les choses de manière bien pensé et utile. Je prend l'exemple de C# qui est un standard... parce que Microsoft a payé les sous pour, chose qu'aurait pu faire Sun/Oracle s'il en avait envie pour Java. Tu prends l'exemple de CORBA, c'est un standard de l'OMG (ce n'est peut-être pas du même niveau que ISO/ANSI/ECMA), le concept est génial mais l'implémentation est tellement complexe que tous le monde l'a abandonné pour les services SOAP et REST.

Pour le timestamp ce n'était pas pour me complexifier la vie, j'avais absolument besoin d'un type "natif" dans le cas cité car l'API C++ que j'utilise (Google Protocol Buffers) ne reconnait pas les types standard.

Bonsoir,

Je réagissais juste à la phrase "(ex: Java, Python etc), c'est qu'il y a un problème au niveau du groupe de standardisation". Ce n'est pas parce que C++ n'intègre pas les mêmes libs que ces langages qu'il y a un problème dans le fonctionnement du comité. Et ce que j'ai essayé d'exposer c'est en quoi le processus d'évolution de C++ n'est pas facilement comparable aux langages qui gravitent pour l'essentiel autour d'une seule implémentation de référence.

Avoir une norme est quelque chose de nécessaire à partir du moment où on a plusieurs implémentations / compilateurs (afin d'assurer une compatibilité commune). Et c'est aussi une nécessité juridique quand plusieurs entreprises coopèrent pour des questions de propriété intellectuelle et de loi anti-cartel - y'à qu'à voir les problèmes entre Oracle et Google à propos de Java.

Pour l'adoption de C++11 en industrie, ça dépend bien sûr de l'industrie. Et ça ne veut pas dire que tout le monde exploite toutes les fonctionnalités. Mais la vitesse à laquelle les compilateurs ont implémenté les évolutions est sans précédent. D'ailleurs Qt va abandonner le support de C++98 l'année prochaine.

Citation:

---

Envoyé par Gugelhupf

Java et Python (que je n'ai pas cité) ne sont peut-être pas des standard ISO/ANSI/ECMA mais ce sont des langages suffisamment efficaces et très utilisés pour être cité. D'ailleurs ces langages ne sont pas des mauvais exemples parce que chacune des nouveautés du C++ est directement inspiré de ces langages (final, override, initialize_list, lambda et j'en passe).

---

Heu... tu es sûr de toi là parce que final et override en C++ çà ne me dit rien; quant aux lambdas elles étaient déjà dans boost/TR1 il y a plus de 10 ans, alors que Java commençait à peine à découvrir les templates.

Citation:

---

Envoyé par Gugelhupf

Enfin pour ce qui est de l'adoption très rapide du C++11 dans l'industrie j'ai un très gros doute mais c'est une impression personnelle.

---

Dans l'industrie, je ne sais pas mais dans les compilateurs, je trouve que le C++11 a effectivement été adopté rapidement, surtout si on compare à l'adoption de python 3 (avec sa rupture de compatibilité) ou à la sortie de perl 6. Cela dit, C++11 a mis 10 ans à se décider donc çà a laissé le temps de voir venir...

Oui les mot-clés final et override font parti du C++ désormais. Boost peut faire des lambdas, Boost reste un framework C++, pas le langage C++.

Citation:

---

Envoyé par Gugelhupf

Oui les mot-clés final et override font parti du C++ désormais. Boost peut faire des lambdas, Boost reste un framework C++, pas le langage C++.

---

Je ne savais pas pour final et override, merci pour l'info.
Pour les lambdas, je voulais juste dire que des programmeurs C++ s'y intéressent depuis un petit moment et n'ont pas attendu Java pour cela.

Il y a des gens magiques ici :mouarf: :mouarf:

Citation:

---

Envoyé par Luc Hermitte

Pour le C++ le développeur lambda n'a toujours que 2 cas à retenir: la copie et la référence. Eventuellement la référence constante. Le reste, c'est pour les développeurs de bibliothèques.

---

Alors si c'est pour les développeurs de bibliothèques, alors pourquoi le C++1y met à disposition ces "outils" pour les développeurs normaux?
Donc le C++1y est en 2 parties: les outils standards et les outils pour les développeurs de bibliothèques.
Même en 3 parties si je ne me trompe pas, parce qu'il y a eu ajout de mots clefs pour marquer son code à destination des outils de compilation/ débogage.

Par exemple pour le passage de paramètres, tu ne parles pas des reference rvalue cela n'est destiné qu'aux développeurs de bibliothèques?

Citation:

---

Envoyé par Aurelien.Regat-Barrel

Du coup, on obtient une boite à outils très large. Et ce n'est pas parce que la caisse à outil contient beaucoup d'outils que je dois tous les utiliser

---

Oui j'ai un vague souvenir [peut-être erroné] qu'une fois les try-catch disponibles, les développeurs en mettaient partout.

C'est bien joli d'avoir une caisse à outils très large [voir même être un peu fier de cette grande largeur :mrgreen:], mais il faut après expliquer chaque outil.

Lorsque je vois les try-catch: quand en mettre? Est-ce qu'ils remplacent le retour d'erreurs C (<- très laid d'après certains)? Est-ce qu'on peut en mettre dans un constructeur? dans un destructeur? ...
Et aussi lire la documentation pour apprendre que le new lance une exception en cas de problème.
Et enfin les try-catch sont [j'ai l'impression] mis au rebut avec le noexcept tellement ils ont été bien expliqués/ utilisés.

Citation:

---

Envoyé par Aurelien.Regat-Barrel

Pour l'adoption de C++11 en industrie, ça dépend bien sûr de l'industrie. Et ça ne veut pas dire que tout le monde exploite toutes les fonctionnalités. Mais la vitesse à laquelle les compilateurs ont implémenté les évolutions est sans précédent.

---

"La vitesse à laquelle les compilateurs": les gens du comité ont sûrement regardé d'un côté le nombre de compilateurs compatibles C99 et de l'autre le taux d'adoption C99 pour en tirer des conclusions.

Pour cela on va me sortir le même laïus: "Les gens du comité proposent et ratifient des choses [pas forcément utiles, pas forcément pour les développeurs normaux, des fois à tord (le mot clef export)], et les autres font ce qu'ils en veulent"

Citation:

---

Envoyé par Luc Hermitte

D'ailleurs, l'idée des CppCoreGuidelines, c'est d'interdire l'utilisation des pointeurs bruts qui sont des tableaux en decay (la traduction m'échappe)

---

Tu confirmes ce que je pensais :mrgreen:

Donc bientôt toute la partie historique C ne sera plus disponible aux développeurs: :mrgreen: (<- *)
Déjà il y a tout un tas d'outils pour ne plus faire de macros et de tableaux fixes [même le faire en mieux]. Et le comité est en train de s'attaquer aux modules et refaire l'inclusion.

Et il va rester quoi au C? les types de bases (et encore certains veulent l'intégration des uint32, uint64, ....) et le fait que tout ne soit pas objet.


Édit: *: Un Java++ , en plus verbeux et sans VM.
Quoique j'ai entendu parler [peut-être à tord] d'un début de réflexion sur l’intégration d'une VM

Citation:

---

Envoyé par foetus

a- Alors si c'est pour les développeurs de bibliothèques, alors pourquoi le C++1y met à disposition ces "outils" pour les développeurs normaux?
Donc le C++1y est en 2 parties: les outils standards et les outils pour les développeurs de bibliothèques.
Même en 3 parties si je ne me trompe pas, parce qu'il y a eu ajout de mots clefs pour marquer son code à destination des outils de compilation/ débogage.

Par exemple pour le passage de paramètres, tu ne parles pas des reference rvalue cela n'est destiné qu'aux développeurs de bibliothèques?



b- Oui j'ai un vague souvenir [peut-être erroné] qu'une fois les try-catch disponibles, les développeurs en mettaient partout.

C'est bien joli d'avoir une caisse à outils très large [voir même être un peu fier de cette grande largeur :mrgreen:], mais il faut après expliquer chaque outil.

Lorsque je vois les try-catch: quand en mettre? Est-ce qu'ils remplacent le retour d'erreurs C (<- très laid d'après certains)? Est-ce qu'on peut en mettre dans un constructeur? dans un destructeur? ...
Et aussi lire la documentation pour apprendre que le new lance une exception en cas de problème.
Et enfin les try-catch sont [j'ai l'impression] mis au rebut avec le noexcept tellement ils ont été bien expliqués/ utilisés.



c- Donc bientôt toute la partie historique C ne sera plus disponible aux développeurs: :mrgreen: (<- *)
Déjà il y a tout un tas d'outils pour ne plus faire de macros et de tableaux fixes [même le faire en mieux]. Et le comité est en train de s'attaquer aux modules et refaire l'inclusion.

Et il va rester quoi au C? les types de bases (et encore certains veulent l'intégration des uint32, uint64, ....) et le fait que tout ne soit pas objet.

---

a- Ce n'est pas parce que le langage offre une large panoplie d'outils que tout le monde en a besoin dans ses développements. A-t-on tous besoin de "asm", de "volatile", de "restrict", ou de "register" en C? Et bien là, c'est pareil. Toutes les applications n'ont pas besoin que leurs développeurs les connaisse.
La formulation employée aujourd'hui: rvalue références, atomics, noexcept, constexpr, méta-programmation, ... pour les dévs de bibliothèques, auto, lambdas, for range loops: pour les développeurs métiers (et autres bien sûr).

b- C'est le problème quand on passe dans un langage sans suivre une formation sérieuse dans ce dernier. C++ n'est pas BASIC: il ne suffit pas de connaitre la liste des fonctions pour savoir s'en servir.
Accessoirement, setlongjump & cie, c'est pas mieux.
try-catch ne sont pas mis au rebut avec noexcept. On avait déjà throw(), et aussi un cerveau pour savoir qu'il est inutile de rattraper une exception depuis une fonction dont la doc dit ne lancer aucune exception.
Pire, try-catch ne doit être employé qu'aux points où l'on sait pouvoir faire quelque chose avec l'exception (notification utilisateur, log, reprise, ...). Ce n'est pas pour gérer les ressources (je sais beaucoup de cours de C++98 sont exécrables et n'ont jamais su enseigner le RAII). Certes en Java <7 on aura un try, mais avec un finally, pas un catch pour les ressources autre que la mémoire.

c- Elle est disponible, mais fortement déconseillée. Chose que l'on retrouve dans pas mal de règles qualités en industrie. Donc rien de nouveau ici non plus.
Quant à ce qu'il reste au C : des archis limitées, les ABIs standardisées, du code en maintenance et des psycho-rigides qui ne veulent que ce langage et surtout pas d'autres qui pourraient faire le même boulot (NB: cela existe dans tous les langages : C++, python, Java, ksh, fortran, ...)

Citation:

---

Envoyé par Luc Hermitte

a- Ce n'est pas parce que le langage offre une large panoplie d'outils que tout le monde en a besoin dans ses développements. A-t-on tous besoin de "asm", de "volatile", de "restrict", ou de "register" en C? Et bien là, c'est pareil. Toutes les applications n'ont pas besoin que leurs développeurs les connaisse.
La formulation employée aujourd'hui: rvalue références, atomics, noexcept, constexpr, méta-programmation, ... pour les dévs de bibliothèques, auto, lambdas, for range loops: pour les développeurs métiers (et autres bien sûr).

---

Mauvaise foi :mrgreen: :mrgreen:
Tu prends en exemple des mots clefs qui n'existent que par eux-même.

Alors que, même si je ne connais pas le C++1y, les rvalue références introduisent la move semantic, constexpr c'est ce qui doit remplacer les macros (et même cela fait plus que cela), la méta-programmation c'est la base du C++1y

Citation:

---

Envoyé par Luc Hermitte

b- C'est le problème quand on passe dans un langage sans suivre une formation sérieuse dans ce dernier. C++ n'est pas BASIC: il ne suffit pas de connaitre la liste des fonctions pour savoir s'en servir.

---

Je note "formation sérieuse". Vous qui martelez que l'on peut apprendre le C++1y sans la case C.

Mais il faut une formation sérieuse: tu m'étonnes :mouarf:

Lorsque je vois que tout le monde attend un vrai objet string, soyons fou un string templaté avec toutes les moulinettes de conversions de l'un vers l'autre std::string<std::UTF8> my_string, non ces boulets nous rajoutent 2 pauvres types qui ne servent juste à pas grand chose mais surtout à alourdir le nombre de boulets à se farder.

Citation:

---

Envoyé par Luc Hermitte

c- Elle est disponible, mais fortement déconseillée.

---

Parce qu'elle est en cours de réflexion je suppose

Citation:

---

Envoyé par Gugelhupf

[*]C++ (10 cas) : par défaut copie de valeur pour tous SAUF pour les tableaux qui passent par référence (2 cas ici), copie de référence pour les pointeurs, passage par référence SAUF le cas où on écrit par exemple un entier en dure et donc obligation de préciser le mot-clé const (2 cas ici), les rvalue reference SACHANT QUE ce dernier a priorité sur un passage par référence constant lors d'une surcharge de fonction (2 cas ici), les pointeurs intelligents divisés en plusieurs catégories (pointeur unique, partagé, et weak pour éviter les références circulaires)... et j'en oublie surement d'autres... mais en gros à vue d'oeil j'ai l'impression que nous sommes passé de 5 cas à 10 cas différents d'un coup... c'est beaucoup pour un concept constituant la base du langage, et tous ces cas particuliers du C++ font que le langage est toujours plus complexe.[/LIST]

---

T'en distingues que 10 ? Petit joueur! Quitte à sortir un chiffre fou, autant y aller franco : 200 passages de paramètres possibles !
Bon après c'est dur d'atteindre ce chiffre j'avoue, mais tu étais pourtant sur la bonne voie en citant unique, shared & weak _ptr, t'aurais pu lister toutes les classes de std, pi celles de Boost s'il restait de la place :)

Citation:

---

Envoyé par foetus

Je note "formation sérieuse". Vous qui martelez que l'on peut apprendre le C++1y sans la case C.

---

Ben, justement, oui… Une bonne formation en C++ est une formation qui, entre autres, ne commence pas par aborder la case C.

Citation:

---

Mais il faut une formation sérieuse: tu m'étonnes :mouarf:

---

Franchement, j’ai vu trop de code pourri dans des langages « accessibles aux débutants », ça m’a convaincu qu’il faut une formation sérieuse tout court, quelque soit le langage. C++ n’est probablement pas le meilleur pour apprendre, mais dans tous les cas, il faudra une formation sérieuse.

Tu cherches à démontrer quoi au juste ?

Citation:

---

Envoyé par foetus

a- Mauvaise foi :mrgreen: :mrgreen:
Tu prends en exemple des mots clefs qui n'existent que par eux-même.

b-Alors que, même si je ne connais pas le C++1y, les rvalue références introduisent la move semantic, constexpr c'est ce qui doit remplacer les macros (et même cela fait plus que cela), la méta-programmation c'est la base du C++1y


c- Je note "formation sérieuse". Vous qui martelez que l'on peut apprendre le C++1y sans la case C.

Mais il faut une formation sérieuse: tu m'étonnes :mouarf:

d- Lorsque je vois que tout le monde attend un vrai objet string, soyons fou un string templaté avec toutes les moulinettes de conversions de l'un vers l'autre std::string<std::UTF8> my_string, non ces boulets nous rajoutent 2 pauvres types qui ne servent juste à pas grand chose mais surtout à alourdir le nombre de boulets à se farder.

e- Parce qu'elle est en cours de réflexion je suppose

---

a- mauvaise foi de qui ? Tout le C n'est pas destiné à tous les développeurs C, et c'est la même chose avec le C++. Et pareil avec le Java aussi : Jouer avec la réflexion ou les annotations ce n'est pas destiné à tout le monde. Même chose avec l'héritage multiple d'interface v8 qui ont des comportements ; et j'ai même envie de dire "inherits" au vu de l'héritage entre List et SortedList dans la v1 de la lib du Java. Pour python on pourrait parler des contournements d'encapsulation, de l'injection de fonctions dans des classes, voire des objets déjà existants, de l'héritage multiple, ...

b- constexpr c'est surtout ce qui doit se taper l'incruste dans les définitions de fonctions inlines. Les macros cela fait longtemps qu'elles sont bannies aussi souvent que possible et en particulier pour définir des constantes. Par contre, en C++17 on pourrait avoir des constantes inlinées histoire d'éviter de mettre le nom dans un .h, et la définition dans un .c(pp). Ca, c'est pour les end-users.

La meta-prog, même si la lib standard s'en sert énormément, ce n'est pas destiné aux end-users. Pas plus en C++98, qu'en C++17 (ni aucune des étapes intermédiaires).

c- On peut définitivement. Il m'empêche qu'il ne faut pas que cela soit fait par des profs qui maitrisent (?) le C et qui croient qu'ils pourront alors maitriser le C++. Pour les exceptions, il y a des règles simples à apprendre. Mais pour les transmettre il faut : les connaitre. Cela peut requérir de ne pas vivre au pays magique où les erreurs n'existent pas (cas de l'essentiel des cours de C), et probablement d'avoir expérimenté un code un temps soit peu réel où des erreurs se propagent entre l'instant de leur détection jusqu'au lieu où on a quelque chose à en faire.
Quand on ne montre que la syntaxe, les élèvent ont vite fait de croire qu'il faut intercepter pour relancer à chaque niveau.

d- Les chaines de caractères et l'UTF-8, c'est pour moi toujours un échec. Il y a des progrès avec boost.locale, mais ce n'est que semi-standard (à l'image des apaches commons (nom à vérifier) en Java)

e- Non. Non. Rien de nouveau non plus. <(c)stdlib(.h)>, <(c)stdio(.h)>, ... sont déjà mises au ban dans les règles qualités, applicables au C++, que je fréquente.

Citation:

---

Envoyé par foetus

Oui j'ai un vague souvenir [peut-être erroné] qu'une fois les try-catch disponibles, les développeurs en mettaient partout.

---

Il y a une super vidéo de Stroustrup à ce propos:
https://www.youtube.com/watch?v=2egL4y_VpYg

En gros, quand un nouveauté débarque dans un langage, elle a tendance à être verbeuse syntaxiquement afin d'être bien visible (comme struct en C). Et les utilisateurs ont tendance à l'utiliser partout parce que c'est nouveau et aussi pour montrer qu'ils maîtrisent cette nouveauté.

Ca a été le cas en C++ avec les exceptions, la POO, les templates... Et, avis perso, je pense que c'est le cas en ce moment avec les rvalue reference.

Citation:

---

Envoyé par foetus

C'est bien joli d'avoir une caisse à outils très large [voir même être un peu fier de cette grande largeur :mrgreen:], mais il faut après expliquer chaque outil.

---

Tu peux le voir ainsi. Tu peux aussi voir ça comme l'apprentissage des mathématiques à l'école : au début on apprend juste l'addition, puis doucement on apprend autre chose en fonction de ses besoins.

Ce qui est discutable je pense c'est de prétendre à la non existence d'une fonctionnalité au motif que l'on n'en n'a pas personnellement besoin [de manière directe du moins]. J'ai l'impression que c'est un comportement plus courant avec C++ qu'avec d'autres langages. Mais je peux me tromper.

Maintenant, si on pose les choses ainsi : "quel est le sous ensemble utile de C++?", alors répondre à cette question est difficile en effet. Les Cpp Core Guidelines sont une aide dans ce sens. Mais d'un autre côté, c'est le boulot d'un développeur senior de répondre à cette question dans un contexte donné. Et si un développeur junior se sent perdu face à ce qu'il convient de faire, je crois qu'il doit davantage se tourner vers sa boite / son prof pour être guidé que vers ceux qui font évoluer le langage.

Aurélien