Discussion :

[Francis Walter]

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

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++

[MikeRowSoft]

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.

[Gugelhupf]

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 - Visualiser dans une fenêtre à part

   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.

[boero-teyssier Greg]

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

[MikeRowSoft]

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.

[Luc Hermitte]

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.

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/

[Francis Walter]

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

[prgasp77]

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 !

[MikeRowSoft]

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.

[Gugelhupf]

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.

[jo_link_noir]

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.

[Luc Hermitte]

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.

[Gugelhupf]

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

[Invité]

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

[jo_link_noir]

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.

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.

[Aurelien.Regat-Barrel]

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 - Visualiser dans une fenêtre à part

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 - Visualiser dans une fenêtre à part

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 - Visualiser dans une fenêtre à part

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

[Gugelhupf]

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.

[Aurelien.Regat-Barrel]

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.

[Invité]

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.

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

[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++.