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

Expert éminent sénior

Le 31/10/2015 à 20:19

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.

[*]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();

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 :

Sélectionner tout

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 :

Sélectionner tout

1
2
3
4
5
chrono::milliseconds getTimestamp() { return 1500ms; }

if (getTimestamp() > 1s) {
    // expiré
}

8

0

Luc Hermitte

Expert éminent sénior

Le 30/10/2015 à 11:39

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.

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.

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

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

d- Complexifient le langage
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...)
f- Nécessitent un temps de formation non négligeable
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/

6

0

Le 31/10/2015 à 12:11

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

5

0

Luc Hermitte

Expert éminent sénior

Le 02/11/2015 à 9:55

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:

(<- *)
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, ...)

4

0

jo_link_noir

Membre expert

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.

3

0

white_tentacle

Membre émérite

Le 02/11/2015 à 10:54

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.

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

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 ?

2

0

Luc Hermitte

Expert éminent sénior

Le 02/11/2015 à 10:57

Envoyé par foetus

a- Mauvaise foi

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

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.

2

0

Aurelien.Regat-Barrel

Expert éminent sénior

Le 02/11/2015 à 15:55

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:

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.

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

2

0

boero-teyssier Greg

Nouveau membre du Club

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.

1

0

Luc Hermitte

Expert éminent sénior

Le 31/10/2015 à 9:20

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.

1

0

Identifiez-vous

Créer un compte

Comment écrire du bon code en C++14 ?

Bjarne Stroustrup, le concepteur de C++ tente de répondre à la question

Identifiant
Mot de passe

Mot de passe oublié ?