Discussion :

[koala01]

Tu n'as pas compris mon objectif initial au travers des commentaires :
m'en servir comme index pour ne pas avoir à lire les lignes de code, et me diriger avec eux au plus près de l'endroit où là seulement j'irai examiner le code avec un but précis.
Cela veut dire entre-autres, ne pas avoir à ouvrir tous les sources ni examiner toutes les fonctions pour lire ce qu'il y a dedans.

Mais c'est une mauvaise excuse. Tu ne dois pas avoir à "indexer" ton code d'une autre manière qu'avec les fonctions qu'il définit.

Tu peux me montrer tout le beau code que tu veux,
je pourrais te répondre que c'est seulement d'après toi qu'il est beau et que son contenu bien choisi.
Je préfèrerai éviter de le lire en entier aux moments critiques, tout simplement parce que le temps ne me sera pas donné pour le faire.

Mais tu n'as pas besoin de le faire non plus!

Si tu as un bug qui n'a rien à voir avec une fonction faitMachinBrol, tu n'as pas besoin d'aller voir la fonction faitMachinBrol quand elle est appelée, car tu sais que l'origine n'en est pas là, point.

Si un bug se balade dans 30 000 lignes de code, on est très mal si on doit compiler de tête 30 000 lignes de code et les interpréter, si l'on en est pas l'auteur.

Et c'est là que je vais te sortir que le bon ouvrier va utiliser les bons outils.
Les bons outils, c'est:

• le débuggeur pour connaitre l'origine et la destination (AKA l'endroit où ca plante) du bug et
• une liste de tests unitaire complete et à jour.

Si tu peux garantir que toutes (ou du moins la plupart de) tes fonctions réagissent exactement de la manière dont elles sont sensées réagir (grace à tes tests unitaires), tu peux déjà réduire ta recherche aux seules fonctions pour lesquelles tu n'as pas cette garantie (qu'il faudrait arriver à donner, soit dit en passant).

"Sauf si c'est bien fait", penseras-tu. Mais si ce jour-là on se rend compte que c'est mal fait ?
Dans quel abîme se trouve t-on alors ?

Ce ne sont pas les commentaires qui t'aideront dans ce cas là. Bien au contraire, ils te ralentiront sans doute bien d'avantage, pour toute une série de raison (dont l'obsolescence dont ils risquent de faire preuve)

On le répète à l'envi: le premier destinataire d'un code n'est pas le compilateur -- comme on pourrait le croire -- mais un lecteur humain.

Hé bien, ca, ca sous-entend qu'un code doit être construit comme un bon roman ou comme une bonne nouvelle: on ne doit pas avoir à réfléchir plus d'une demi seconde pour arriver à le comprendre.

Mais quand on en arrive à se dire qu'un commentaire "devrait aider la compréhension", c'est la preuve (je dirais presque par l'absurde) du fait que l'on n'a échoué à garantir cette qualité essentielle du code. Et cela ne fait qu'appliquer un emplâtre sur une jambe de bois, car, au mieux, il faudra que le lecteur "retrouve" le commentaire pour arriver à se dire "ah oui, c'est ca qu'on avait dit", au pire, le commentaire n'aura pas été mis à jour en même temps que le code, et l'information qu'il donnera sera -- au mieux -- purement et simplement erronée. Ce qui n'aidera de toutes façons pas à la compréhension.

De plus, le code est quand même malgré tout (faut-il le rappeler ) destiné dans un second temps au compilateur qui ignorera purement et simplement les commentaires. On peut donc écrire les plus monumentales conneries sous forme de commentaire, elles n'auront de toutes manières aucun impact sur la traduction effectuée par le compilateur (ou par l'interpréteur, selon le langage).

Sauf que, ces conneries, nous les aurons lues dans un premier temps. Et elles auront forcément eu un impact sur notre perception du problème. Et si c'étaient des conneries, parce que le commentaire "n'est pas à jour", cet impact ne pourra pas être autre chose que négatif.

Si bien que, il n'y a pas trente-six solutions au final: ce qui compte pour le compilateur, c'est le code hé bien ce qui doit compter pour le lecteur, c'est aussi le code. Et uniquement le code. Il n'y a aucune raison de faire en sorte que les deux protagonistes dans cette histoire puissent avoir des "sources d'informations" différentes. Car c'est quand on commence à se baser sur des sources d'informations différentes que les problèmes commencent à arriver: on trouvera toujours une source qui dit A alors que l'autre dit B.

Eviemment, cela nous oblige à nous poser une autre question: Comment faire pour qu'une même source d'informations (le code et rien que le code) soit aussi bien compréhensible par l'humain que par le compilateur Car, il n'y a rien à faire, on n'est décidément pas fait pareil.

Mais la réponse à cette question est toute simple: il faut que le code soit expressif. Plus le code sera expressif, plus l'humain aura facile à le lire et à le comprendre. Quant au compilateur, lui, il s'en fout pas mal: il fera ce qu'on lui dit quoi qu'il arrive.

Maintenant, tu demandes comment déterminer qu'un code est assez expressif... Hé bien, c'est tout simple: si une seule personne ayant à voir avec le code vient à poser une seule question concernant le code qu'elle lit, c'est qu'on a foiré notre coup, et qu'il faut le rendre plus expressif encore. Et ce n'est donc pas moi, l'auteur du code, qui dit que mon code est beau et expressif, c'est le reste de l'équipe, du débutant au vieux briscard, qui confirme qu'ils arrivent à comprendre le code sans avoir d'effort particulier à faire. Cela s'appelle la revue par les paires.

Mais, grâce à cette confirmation, je peux dormir sur mes deux oreilles: s'il y a une erreur dans mon code (je ne suis qu'un humain, j'en fais aussi), je sais que n'importe qui reprenant mon code arrivera à en déterminer l'origine et donc à la corriger.

Maintenant, je suis le premier à le reconnaître: ca demande un travail de dingue d'arriver à produire un code suffisamment expressif que pour qu'il puisse être compris sans avoir le moindre effort à faire. Mais c'est le boulot des développeurs, et ils sont grâcement payés pour le faire. Ce qui devrait être une raison supplémentaire (si beson en était) pour qu'ils le fassent correctement.

[oodini]

Maintenant, je suis le premier à le reconnaître: ca demande un travail de dingue d'arriver à produire un code suffisamment expressif que pour qu'il puisse être compris sans avoir le moindre effort à faire. Mais c'est le boulot des développeurs, et ils sont grassement payés pour le faire. Ce qui devrait être une raison supplémentaire (si besoin en était) pour qu'ils le fassent correctement.

La paye ne rentre pas en ligne de compte. Ce travail n'est pas encouragé et valorisé.
Il faut être "pragmatique" et produire vite.

[koala01]

La paye ne rentre pas en ligne de compte. Ce travail n'est pas encouragé et valorisé.
Il faut être "pragmatique" et produire vite.

Ah, désolé... J'ai eu la chance de travailler sur des projets sur lesquels on préférait un code de qualité faisant correctement ce à quoi on s'attendait à un code bâclé sur lequel il faudrait revenir sans cesse.µ

Et puis, une production rapide n'est pas antinomique à une production de qualité! Bien au contraire: c'est grâce à une production de qualité que l'on peut arriver à une production plus rapide.

Le seul frein à la qualité du code, en définitive, c'est le niveau de "je m'en foutisme" de celui qui l'écrit.

Et il est clair qu'avec du "vilain code" (quelle que soit la définition que l'on donne à ce terme), on se trouve facilement confronté au syndrome de la vitre brisée: le code est déjà vilain, pourquoi devrais-je faire un effort pour le rendre "plus beau"

Mais si les développeurs avaient un tant soi peu de conscience professionnelle, il appliqueraient au contraire la "règle du boyscout" : on laisse un code plus propre en repartant qu'il ne l'était lorsqu'on est arrivé. Et je peux t'assurer qu'il suffit d'un seul développeur appliquant cette règle pour que, a termes, cela devienne la règle générale.

• Ca ne prend pas longtemps de choisir correctement un identifiant.
• Ca ne prend pas longtemps de découper une fonction en deux "sous fonctions" qui pourront être testées séparément, et qui s'occuperont d'un seul truc particulier
• Ca ne prend "qu'un peu plus longtemps" de réfléchir au respects des principes de conception avant d'écrire son code.

Même dans un état de stress absolut où il y a eu plantage en production, il faut s'astreindre à cette politique du boyscout. Car il n'y a que de cette manière que l'on évitera les dettes techniques, et que l'on gagnera du temps, non seulement au moment même, mais aussi plus tard, et ce, bien que l'on n'en ai pas forcément conscience.

[grunt2000]

Bon, je vais abandonner ce hors-sujet (que j'ai moi-même contribuer à initier) parce que nous ne sommes pas d'accord mais nous avons échangé assez arguments pour faire valoir nos positions respectives.

En tout cas, merci aux deux membres de Developpez.com d'avoir écrit cette présentation des nouveautés de C++ 11 en 2012.
C'est très synthétique et facile à ingérer.

Je vois que cette évolution C11 ++ est surtout un rattrapage de quelques fonctionnalités que Java avait acquises jusqu'à sa version 5, avec en surplus l'introduction des lambdas que Java ne recevra que beaucoup plus tard.
Du coup, ceci ne sera pas trop complexe à appréhender.

Mais je gagnerai quand même plutôt à me faire une recherche thématique.
1) Comment fait-on une lecture ou des écriture proprement dans un fichier en C++ 14, aujourd'hui ?
- Et quelques variantes : transformation d'un fichier XML en objets.
- Flux.

2) Comment accède t-on à une base de données également, de la manière la plus élégante et appréciée possible ?

3) Comment réalise t-on un service transactionnel (c'est à dire qui interroge et agit des bases de données lui-même ou par le biais d'autres services dans le cas d'utilisation qu'on lui a demandé de résoudre, puis au dernier moment : peut tout annuler, si c'est requis) ?
Il doit falloir un bout de framework pour faire l'équivalent des @Service @Transactional de Java.

[Luc Hermitte]

a- Bon, je vais abandonner ce hors-sujet (que j'ai moi-même contribuer à initier) parce que nous ne sommes pas d'accord mais nous avons échangé assez arguments pour faire valoir nos positions respectives.

b- Je vois que cette évolution C11 ++ est surtout un rattrapage de quelques fonctionnalités que Java avait acquises jusqu'à sa version 5, avec en surplus l'introduction des lambdas que Java ne recevra que beaucoup plus tard.
Du coup, ceci ne sera pas trop complexe à appréhender.

Mais je gagnerai quand même plutôt à me faire une recherche thématique.
1) Comment fait-on une lecture ou des écriture proprement dans un fichier en C++ 14, aujourd'hui ?
- Et quelques variantes : transformation d'un fichier XML en objets.
- Flux.

2) Comment accède t-on à une base de données également, de la manière la plus élégante et appréciée possible ?

3) Comment réalise t-on un service transactionnel (c'est à dire qui interroge et agit des bases de données lui-même ou par le biais d'autres services dans le cas d'utilisation qu'on lui a demandé de résoudre, puis au dernier moment : peut tout annuler, si c'est requis) ?
Il doit falloir un bout de framework pour faire l'équivalent des @Service @Transactional de Java.

a- Oui, on tourne vite en rond là dessus
b- Attention, tu risques d'invoquer un autre troll ici

1- Bonne question. Il existe divers frameworks qui se veulent efficaces pour le Json et qui visent le C++14 p.ex. Pour XML, la question est : "pars-tu de spécifications xsd?" Si oui, tu vas plutôt être intéressé par des solutions de binding comme code-synthesis XSD. Mais attention à la licence triple. Ayant produit des logiciels sous licences libres type GPL, j'ai pu m'en servir.
Si tu n'as pas besoin de bindings (auquel cas je préfère json à xml), rapidXML est interessante. Xercès-C++ est non-convivial, préhistorique, mais c'est probablement le plus complet (il offrira la validation des XML). (Code Synthésis XSD va venir en sur-couche à Xerces-C++).
Il y a 3ans (?) les gars de code-synthésis avaient présenter une lib moderne de manipulation d'XML qu'ils voulaient pouvoir utiliser à la place Xercès-C++. Je n'ai pas eu de news depuis, je ne sais pas où cela en est.

"flux"? Tu veux dire pour sérialiser de manière plus générale? Cela va dépendre des formats. XML, json, netCDF, HDF, images, ... Il y a aussi boost.serialize -- vois boost comme les apaches commons: un vivier/laboratoire de bibliothèques pour le C++
Pour les logs, spdlog m'a tapé dans l'oeil.
Pour l'i18n, boost.locale offre une surcouche C++ conviviale à ICU. Mais tu as aussi tout Qt.

2- Pareil j'ai vu plusieurs projets d'ORM. Celui qui me tape dans l'oeil, c'est celui dont l'auteur donne des présentations aux cppcon: https://github.com/CppCon/CppCon2017...Con%202017.pdf
Après, il existe des frameworks plus traditionnels. Je me souviens d'un participant du sdz/oc faire de la pub pour son framework (http://www.qxorm.com/qxorm_fr/home.html). Je me souviens aussi de SOCI (https://github.com/SOCI). CodeSynthesis a aussi sa solution (http://www.codesynthesis.com/products/odb/).
Bref, on ne manque pas de possibilités.

3- Si le framework le gère nativement, rien à rajouter. Sinon, Avec le C++17 on peut avoir des rollbacks automatiquement (sans avoir à désarmer des façon explicite le rollback) de façon très simple. Je n'ai pas d'article sous la main, mais j'en avais vu plusieurs. Les mots clés: "scope_fail" et "scope_success", qui renvoie p.ex. http://www.open-std.org/jtc1/sc22/wg...17/p0052r3.pdf Mais il y a d'autres articles plus pédagogiques.

[grunt2000]

Pouvez-vous me donner un lien vers les convention d'écriture de code C++ aujourd'hui ?
Parce que quand je l'ai quitté en 2000, sous MFC, je connaissais des choses comme : mettre l'accolade ouvrante de fonction à la ligne en dessous du prototype de la méthode et préfixer ses variables membres par m_ dans la classe. Ces variables membres étaient souvent mises au bas de la classe.
Mais je crois aussi que j'étais sujet à des "règlements" qui n'appartenaient qu'au monde Windows d'alors : les variables membres de type chaîne de caractères étaient souvent préfixées m_sz : m_szNom, m_szPrenom, etc.

Si je mets trois lignes dans un code d'aujourd'hui, je ne voudrais pas qu'on me fasse immédiatement les gros yeux !
Surtout que je ne serai pas sous Windows mais sur Debian.

Je viens m'acheter une version de Programmez en Langage C++ de C. Delannoy, afin de retrouver ce que je savais jadis et me remettre à jour plus rapidement et de manière organisée. Il porte jusqu'à la norme C++ 17.
Tout de même, je tiens à le dire : Claude Delannoy, il m'a accompagné toute ma vie de développeur C++, et même de C, je crois. Faudrait que je m'en assure, 20, 30 ans en arrière... Quand même, c'est impressionnant !

[Bousk]

Y'a pas de telle règle, tout juste des bonnes pratiques prêchées par certains, c'est chaque boîte qui crée ses règles d'écritures, nommage etc.

[koala01]

De manière générale, chaque équipe fera à peu près à sa sauce... Le tout, c'est de veiller à être cohérent, et à utiliser strictement les même conventions sur l'ensemble du projet

On croise encore souvent des projets qui préfixent les données membres de m_. Mais on trouve également des projets pour lesquels on suffixe le nom de la donnée membre d'un underscore.

Et, l'un dans l'autre, avoir m_membre ou membre_ n'est jamais qu'une question de gout, le tout étant bien sur que tout le monde fasse pareil au sein du projet

Pour la casse des noms, c'est pareil : certains projets vont utiliser la notation UpperCamelCase pour les types et le lowerCamelCase pour le reste, par exemple class MaClasseQuiFaitCeci et void laFonctionQuiFaitBouh(), d'autres écriront tout en minuscule, en séparant les différents termes par un underscore sous une forme proche de class ma_classe_qui_fait_ceci et void la_fonction_qui_fait_bouh().

Et, enfin, pour ce qui est de l'indentation, on retrouve aussi bien le

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
void foo()
{
    for(/* ... */ )
    {
        /*chaque fois x espaces de décalage vers la droite */
    }
}

que tu connais que le

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
void foo(){
    for(/* ... */ ){
        /*chaque fois x espaces de décalage vers la droite */
    }
}

qui est juste un peu plus compact ou même encore que d'autres conventions qui placent les accolades à différentes positions

Finalement, les seules règles à respecter sont:

1. les conventions doivent être cohérentes, et, si possible, permettre d'identifier ce à quoi on a affaire
2. on doit pouvoir repérer les blocs d'instructions facilement
3. les conventions doivent être suivies tout au long du projet

Pour le reste, tu fais, en gros, exactement comme bon te semble

[grunt2000]

Bon, ben tant mieux, merci.
Comme ça, je vais pouvoir être détendu, de ce côté-là.

[jo_link_noir]

Je suis étonné de voir que personne n'a tiqué sur le livre, alors que les Delannoy sont fortement déconseillés.

Pas plus tard que cette semaine quelqu'un a demandé un avis dessus: https://www.developpez.net/forums/d1...oche-19-octob/

[grunt2000]

Bon, ben me voilà bien vexé d'avoir le mauvais livre !
Voilà que je lui trouve plein de défauts à présent aussi, et qu'il me déplaît à mon tour. Mais je me demande par lequel le remplacer. En français, idéalement. Sinon, je me ferai bien à l'anglais.

Voici mes nouvelles questions :
1) C++ a autant de de projets ayant donné lieu à des bibliothèques utilitaires que Java en a qui ont produit des artefacts incorporables.
Dans le monde Java, ils sont rangés dans des dépôts "à la Maven repository" et connaître cette url (connue d'emblée de Maven, Gradle et autres) suffit à intégrer dans son projet n'importe quoi dont on connait les coordonnées "groupId, artifactId".
Quel est l'équivalent en C++ ? L'endroit où l'on peut trouver la plus grande majorité de tout ce que la communauté open-source ou autres tierces-parties ont produit et mis à disposition ?

2) Maven est d'une lourdeur incroyable et réclame jusqu'à deux ans d'apprentissage au long cours pour le maîtriser bien,
mais il propose une chaîne qui compile, exécute les tests unitaires, provoque au besoin des tests d'assemblage / intégration (avec serveurs fictifs ou embarqués, idem pour les bases), déploiement et placement sur un dépôt pour mise à la disposition du public.

Existe t-il un outil qui assure des fonctionnalités similaires pour les projets C++ ?
CMake le fait ou bien l'on passe sur Gradle (que je vois comme le successeur de Ant, qui était le plus proche de ce que je me rappelle du make) ?
Ou bien ce n'est pas dans l'esprit de la conduite des projets et l'on a des habitudes différentes, et dans ce cas lesquelles ?

Merci !

EDIT @koala01 : Merci pour le sacré détail de tes explications, et pour le conseil du livre !
Mais le lippmann, je le trouve seulement dans sa cinquième édition, et elle ne va que jusqu'au C++ 11.
N'est-il pas devenu un peu ancien ?

[koala01]

(1) La réponse "simple": ce n'est pas dans les habitudes d'avoir un système d'intégration continue "global".

Quand on sait qu'une application compilée pour windows ne fonctionnera pas sous linux, et que, en plus, la distribution X de linux va sans doute utiliser un système de gestion des paquets différents de la distribution Y (à moins que, par chance, elles aient toutes les deux un ancêtre commun comme ubuntu Vs mint), on se rend assez facilement compte que cela deviendrait rapidement ingérable

C'est la raison qui fait que la plupart des bibliothèques et applications open-sources sont généralement distribuées sous formes de sources. Alors, bien sur, on pourra dire que "on n'a pas le choix, c'est la licence qui impose qu'on fournisse les sources", mais le fait est surtout que, si tu veux distribuer une bibliothèque ou une application sous forme binaire pour toutes les configurations possible, tu es loin d'avoir fini ta journée

Du coup, on fait souvent appel à différents outils, pour différentes raisons:

• Git (svn, Hg, autre) pour maintenir l'historique des version, d'autant plus que la plupart des sites qui proposent de tels hébergement viennent avec des système de bugtracking et souvent même avec un wiki et d'autres outils de "communication" (ex: github, sourceforge, ...)
• S'il n'est pas disponible chez l'hébergeur, un système de bugtracking (bugzilla, ou autre)
• Eventuellement (en "interne") un build server (comme jenkins) pour, couplé avec le système de gestion de versions concurrente pour lancer l'ensemble de la compilation et des tests unitaires à chaque commit
• j'en oublie sans doute

Pour linux, tu trouveras également de nombreux miroir ftp qui te permettront d'obtenir les sources, en gros de tout ce que l'on peut trouver (en open sources) sous linux; mais il n'y a pas -- à ma connaissance -- d'initiative équivalente sous windows.

(2) Le lipman dans sa dernière version semble avoir la faveur du public... Mais il est en anglais

Et, de manière générale, j'ai l'impression qu'il n'y a que très peu d'auteurs francophones, et donc de bouquins dont la langue originelle soit le français.

De même, je crois qu'il faut se méfier des traductions (qu'il vaut toujours mieux lire la version originale que la traduction des livres), surtout quand ils parlent de C++, car la qualité de la traduction est souvent fort variable, mais oscille régulièrement entre "mauvaise" et "déplorable" (à quelques exceptions près dirons nous )

(3) CMake peut récupérer un numéro de version / de branche sur un serveur git (et peut-être svn), et, tant qu'à faire, l'ensemble du code source pour cette branche, cette version particulière.

Par contre, il ne s'occupe pas -- à ma connaissance -- de propager les commit. Et c'est normal, vu que c'est à la base un outil de configuration du projet

[JolyLoic]

Sur ce point, le C++ est bien plus complexe que le Java, avec ses options de compilation dans tous les sens, incompatibles les unes avec les autres... Il commence néanmoins à apparaître des gestionnaires de package, fournissant même des packages pré-construits (qui proposent donc diverses versions des binaires, j'ai par exemple compté 58 versions sur le premier exemple que j'ai ouvert).

Le plus connu actuellement est conan, avec des repositories comme https://bintray.com/conan/conan-center et https://bintray.com/bincrafters/public-conan (et la possibilité bien entendu d'héberger localement ton propre repository pour des bibliothèques internes). Après, certains utilisent ces repositories publics, d'autres préfèrent générer eux même les différents packages à partir des sources, pour être certains de contrôler ce processus et d'avoir exactement la configuration attendue dans une entreprise (la 59ème version, qui est exactement comme les autres, sauf que telle macro absolument indispensable est elle aussi définie).