Comment écrire du bon code en C++14 ?
Réponse de Bjarne Stroustrup

Le , par Francis Walter, Expert éminent sénior
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 ».


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

Source : Writing Good C++14

Voir aussi :
Cours C++
Forum C++


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


 Poster une réponse

Avatar de MikeRowSoft MikeRowSoft - Provisoirement toléré https://www.developpez.com
le 29/10/2015 à 16:21
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.
Avatar de Gugelhupf Gugelhupf - Modérateur https://www.developpez.com
le 29/10/2015 à 16:41
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.

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).

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 ) :
    Code : Sélectionner tout
    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).


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.
Avatar de boero-teyssier Greg boero-teyssier Greg - Nouveau membre du Club https://www.developpez.com
le 29/10/2015 à 16:59
  • 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.
Avatar de MikeRowSoft MikeRowSoft - Provisoirement toléré https://www.developpez.com
le 29/10/2015 à 17:12
Citation Envoyé par Gugelhupf  Voir le message
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.
Avatar de Luc Hermitte Luc Hermitte - Expert éminent sénior https://www.developpez.com
le 30/10/2015 à 11:39
Citation Envoyé par MikeRowSoft  Voir le message
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  Voir le message
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.

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).


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/
Avatar de Francis Walter Francis Walter - Expert éminent sénior https://www.developpez.com
le 30/10/2015 à 11:46
J'ai ajouté le lien de l'annonce du C++ Core Guidlines dans le premier message.
Avatar de prgasp77 prgasp77 - Membre émérite https://www.developpez.com
le 30/10/2015 à 11:57
Citation Envoyé par Luc Hermitte  Voir le message
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.


Meurtre par abus de négation. Appelez la police !
Avatar de MikeRowSoft MikeRowSoft - Provisoirement toléré https://www.developpez.com
le 31/10/2015 à 0:21
Citation Envoyé par Luc Hermitte  Voir le message
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.
Avatar de Gugelhupf Gugelhupf - Modérateur https://www.developpez.com
le 31/10/2015 à 0:47
Citation Envoyé par Luc Hermitte  Voir le message
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.
Avatar de jo_link_noir jo_link_noir - Membre chevronné https://www.developpez.com
le 31/10/2015 à 3:51
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.
Contacter le responsable de la rubrique C++