Obtenir la pile d'appels en cours d'exécution

Version imprimable

03/12/2018, 19h16
Teaniel

Obtenir la pile d'appels en cours d'exécution

Bonjour,

Je suis sous QTCreator 4.7.2 / QT5.10.0 MinGW32 sous Seven.
Tout d'abord désolé si je ne suis pas au bon endroit du forum, mais compte tenu du sujet, je pense que c'est le moins mauvais emplacement pour le poser (lié à la fois à C++11 et QTCreator).
J'ai actuellement un souci d'exception ayant lieu avant le démarrage du programme, (_M_Construct : null not valid), que je n'arrive pas à situer, et qui ne se laisse pas tracer dans le debugger.
La seule solution que je vois actuellement est de modifier basic_string.tcc pour y ajouter un affichage de la pile d'appels au moment où il lance cette exception (j'en ai exactement repéré l'emplacement).
Cependant je ne trouve pas comment faire pour afficher cette trace. Quelqu'un connaitrait-il une fonction capable de réaliser cela?

Par avance merci, et encore une fois désolé si mon sujet est mal placé. Toute remarque ou suggestion sera acceptée.
A bientôt,
Marc
03/12/2018, 20h42
jo_link_noir

Pour commencer, utilises-tu des variables globales ? Parce si le main n'est pas encore lancé, c'est forcement une globale qui initialise n'importe comment un std::string.
03/12/2018, 22h16
koala01

Salut,

Pour continuer :

A priori, _M_Construct : null not valid est le genre de message lorsqu'une exception est lancée (par l'un des constructeur de std::string, que tu construis n'importe comment, comme l'a si bien fait remarquer jo_link)

Le problème, c'est que, sans voir ton code, il nous sera particulièrement difficile de t'aider. L'idéal serait donc que tu nous montre ton code pour que l'on puisse voir un peu "où tu te plante".

Mais, si ton code est particulièrement important, tu peux envisager de te limiter aux seules parties qui contiennent des variables globales, car ce sont les seules qui peuvent faire planter l'application avant même qu'elle n'aie démarrer.

Et, sinon, tu peux envisager de fournir le code sur un serveur git (github ou framagit(*) ) en te disant que, de toutes façons, ce ne sera surement pas perdu: un projet est forcément quelque chose de "vivant", qui évolue (toujours vers une complexité plus importante) au fil du temps, et que "tôt ou tard", tu essayera d'apporter une modification qui risque de "tout casser".

Git étant un outil de gestion de versions concurrentes, c'est l'outil idéal pour te permettre de "revenir en arrière" (et donc pour annuler une modification malheureuse) quand le besoin s'en fait sentir ;)

L'un dans l'autre, tout projet qui n'est pas destiné à être "jeté" dés qu'on a vu que cela fonctionne devrait systématiquement être placé sous le contrôle d'un tel outil, tout comme il devrait contenir des tests unitaire, pour s'offrir une chance de garantir la "meilleur qualité possible" au projet ;)
03/12/2018, 22h21
Teaniel

Merci pour ta réponse. Joli_link_noir.
Tu as sans doute raison, même à coup sur je dirais.
Cela dit, j'ai été incapable de la trouver dans la centaine de fichiers et de classes qui font actuellement partie de mon projet (recherches globales et tout).
Les seuls mots clé static que je trouve sont soit dans des fonctions soit pour en déclarer (ou alors il est passé au travers de mes recherches). Et aucun ne déclare de string... Même pas léopard... Bon, je sors... :aie:
C'est pourquoi je pose cette question. Cela dit, dans les forums que j'ai visité il y en a un qui parlait d'un sysinfo.h avec une fonction dont je ne me souviens pas du nom mais manifestement ni le fichier ni la fonction ne sont plus référencées (le post date de 2006 tu me diras). Raison de mon petit espoir d'obtenir une réponse ici.

Encore merci, et à bientôt,
Marc
03/12/2018, 22h43
Teaniel

Merci aussi Koala01 pour ta réponse.
Je suis bien conscient de tout cela, et en effet il semble que c'est ce à quoi je suis condamné...
Mon projet est sous svn, et je peux effectivement faire un retour. Cela dit j'ai fait une petite erreur, en enregistrant un bond un peu trop important, du coup je vais devoir reprendre beaucoup de boulot...
En plus, c'est un ancien projet (plus de 20 ans, écrit en C++Builder4) que je reprends, que je veux améliorer et dont je ne maitrise plus parfaitement tous les secrets :p . Cela dit aujourd'hui il fonctionne encore dans son ancienne version.
Le fait est que là je suis à la recherche d'une solution moins coûteuse, et partager mon code ne serait sans doute pas une bonne idée, car si pour moi cela correspond déjà à chercher une épingle dans une meule de foin, je suppose que ce serait bien pire pour vous... Donc s'il pouvait être possible de placer un piège dans _M_Construct, ce serait idéal...
J'ai également lu qu'on pouvait debugger des exécutables. Cela pourrait peut être contourner le démarrage au main. Technique envisageable? Si oui comment fait-on?
Encore merci :)
A bientôt!
Marc
03/12/2018, 23h04
Bousk

Si ça crash avant le lancement du programme, tu n'as pas de stack.
Sous VS ces crashs sont totalement gérés et visibles dans le debugger. Qt Creator et Mingw ne savent pas les afficher ? :koi:
Sinon tu peux essayer de supprimer le constructeur dans basic_string.tcc et voir où la compil' plante, mais je trouve étrange que ce constructeur puisse échouer.
04/12/2018, 01h05
Teaniel

Merci Bousk
En fait le message indique que j'ai du passer un char * nullptr sans doute. Je ne sais pas trop où et c'est bien là le problème, d'autant que cet argument peut très bien résulter d'un calcul...
Néanmoins, ton idée d'abimer ce constructeur me plait.
Je vais la mettre en oeuvre. Enfin pas ce soir, je dois un peu dormir encore cette nuit...

Merci à toi ;)
Et à bientôt!
04/12/2018, 03h31
koala01

Citation:

Envoyé par Teaniel

Merci aussi Koala01 pour ta réponse.
Je suis bien conscient de tout cela, et en effet il semble que c'est ce à quoi je suis condamné...
Mon projet est sous svn, et je peux effectivement faire un retour. Cela dit j'ai fait une petite erreur, en enregistrant un bond un peu trop important, du coup je vais devoir reprendre beaucoup de boulot...

Oh, je parle de git parce que c'est le système qui a le "vent en poupe"...
Un lien svn est tout aussi utile qu'un lien git pour nous

Citation:

En plus, c'est un ancien projet (plus de 20 ans, écrit en C++Builder4) que je reprends, que je veux améliorer et dont je ne maitrise plus parfaitement tous les secrets :p . Cela dit aujourd'hui il fonctionne encore dans son ancienne version.

Oufff...
oui, évidemment...

Citation:

Le fait est que là je suis à la recherche d'une solution moins coûteuse,

Cela peut effectivement se comprendre!

Sur ce point, Qt semble être le remplaçant idéal ;)

Cependant, si ton projet a été développé selon les "canons de l'époque", le passage de l'un à l'autre risque de ne pas se faire sans mal : je ne serais pas particulièrement étonné si "l'imprégnation" de la VCL était "maximale" dans ton projet. Me trompés-je:question:

A tel point que je me demande si une réécriture complète pure et simple ne devrait pas être envisagée, ne serait-ce que comme une certaine manière d'abandonner les dettes techniques que tout projet "antédéluvien" traine généralement derrière lui comme des boulets.

Car l'alternative qui (pourrait) consiste(r) à commencer par réduire l'imprégnation de la VCL pour en limiter son usage à la seule IHM de ton projet ne prendrait sans doute pas moins de temps (en plus de rendre l'idée d'un refactoring supplémentaire pour réduire les dettes techniques beaucoup plus compliquée à mettre en oeuvre)

Enfin, il va de soi que c'est toi qui décide, hein ;)

Citation:

et partager mon code ne serait sans doute pas une bonne idée, car si pour moi cela correspond déjà à chercher une épingle dans une meule de foin, je suppose que ce serait bien pire pour vous...

Oh, je ne parirais pas trop là dessus, si j'étais toi ;) :D

Ne serait-ce que parce que tu connais l'adage : il y a toujours plus dans deux têtes que dans une ;)

Et puis, pensons positif : à moins -- bien sur -- que ton projet ne soit commercial et toujours en exploitation (ce qui serait une raison largement suffisante pour ne pas souhaiter en dévoiler le code source ;)), qu'aurais tu à perdre à le mettre sur un serveur (git, SVN, mercurial ou même CVS si tu veux) public et à nous en fournir l'URL, à part ... le temps nécessaire à la manœuvre :question:

Mais penses aussi au bénéfice que tu pourrais obtenir en le faisant : qui sait, "quelqu'un" pourrait aussi passer justement "par hasard" sur le fichier et trouver l'erreur, ce qui te permettrait de corriger le problème :D

Le bénéfice me semble -- pour potentiel qu'il puisse être -- largement supérieur au risque encourru! Qu'en penses tu :question:
04/12/2018, 07h49
Teaniel

1 pièce(s) jointe(s)

Bonjour à toi Koala01
(lol y'en a qui dorment encore moins que moi ;))

Tu as encore une fois raison sur tous les plans.
Cela dit, j'ai tout de même fait preuve à l'époque d'une certaine clairvoyance :
- La partie 'Données' n'est que peu imprégnée de Builder (quelques propriétés à remplacer par leur getter/setter, et les traces de la VCL à retirer), surtout parce que je n'utilise pas de BDD (question pratique car le programme doit rester léger).
- La partie UI est parfaitement irrécupérable, ne m'a de toutes façons jamais plu, et je vais beaucoup travailler dessus (dès que le reste fonctionnera, ce qui ne saurait tarder ;)).
Ce que j'ai basculé dans le nouveau projet est juste la partie données. Une fois cette gestion corrigée, il me restera à re-concevoir l'IU.
Je 'ai bien sur déjà essayé de réécrire complètement 'from scratch', mais je suis trop imprégné du modèle que j'avais choisi, et je n'arrive jamais à un truc réellement fonctionnel. Du coup je me suis dit qu'il serait plus simple de partir de ce qui existe. Mon objectif est ici simplement de le faire fonctionner, et ensuite de le faire évoluer.
Je vais voir pour le mettre sur un serveur Git ou autre pour le partager. Cela dit, je n'ai jamais fait cela, et il va me falloir un petit temps.
En fait, je cais plutôt le mettre en PJ dans un 7z. Voici le lien Pièce jointe 432021.
J'espère que vous serez indulgents, presque tous mes choix étaient déjà discutables à l'époque. En particulier il y a un peu trop d'interdépendances entre les modules (raison pour laquelle je n'arrive pas vraiment à tester séparément).
De plus, comme c'était du code qui n'était pas destiné à être partagé, il est assez peu commenté. Je ne suis qu'un simple amateur, sans aucune prétention par rapport à la qualité de son code (raison supplémentaire de ma réticence à partager)...

Citation:

Sur ce point, Qt semble être le remplaçant idéal

lol Pas photo. J'ai évidemment commencé par là. Au bout d'une heure de travail le compilo m'a sorti une erreur interne sans autre référence. Impossible de savoir quoi changer. Ca semblait lié aux template. En désespoir de cause, j'ai commencé le portage, et évidemment rien de tel ne s'est produit avec Mingw32/QtCreator. En plus, autant à l'époque j'étais fan de Borland, autant maintenant ce GUI me déçoit (enfin bon, c'est pas le propos).
Voila
.
Encore merci, bon courage :)
Et à bientôt,
Marc
04/12/2018, 07h57
Luc Hermitte

C'est clairement une std::string construite à partir d'un 0/nullptr/NULL

Regarde à utiliser l'address sanaitizer de clang. Il est parfait pour avoir la pile d'appel au moment du crash. Ceci dit, c'est bizarre que gcc ne puisse pas te la donner -- après il faut dire que je fuis mingw, il n'est pas impossible que le portage de gcc/gdb y soit bancal.

N'hésite pas à utiliser d'autres environnements (VC++ sous windows, gcc/clang sous unix)

EDIT: Détail, si tu catches toutes les exceptions, tu vas perdre ta pile d'appel et donc tout contexte côté debugger (ou pourquoi les exceptions de logique c'est le mal...). Regarde à la place si tu ne peux pas demander à ton debugger de s'arrêter aux exceptions. Ils en sont capables, mais il faut leur dire.
04/12/2018, 10h51
bacelar

En plus des remarques pleines de pertinence de mes VDD, et malgré le fait que je n'utilise jamais (plus) mingw, j'ai quelques remarques.

Sur les conneries les plus évidentes, le compilateur est ton meilleur ami, et il faut lire TRÈS attentivement les warning qu'il remonte ET aussi le configurer pour qu'il remonte le plus de warning possible.

L'erreur est potentiellement dans ces warning.

Si vous compilez avec les informations de débugging ("-g" pour GCC, etc...), un débogueur, qu'il soit "en ligne" ou post-mortem, sera capable d'indiquer la ligne de code du problème (même si c'est avant le main) ainsi que les valeurs des variables.

Pour utiliser les débogueurs en post-mortem, configurez votre système pour qu'il génère des "dump" et cas de crash.
04/12/2018, 14h00
koala01
Citation:

Envoyé par Teaniel

Cela dit, j'ai tout de même fait preuve à l'époque d'une certaine clairvoyance :
- La partie 'Données' n'est que peu imprégnée de Builder (quelques propriétés à remplacer par leur getter/setter, et les traces de la VCL à retirer), surtout parce que je n'utilise pas de BDD (question pratique car le programme doit rester léger).

Joliiii!

Ca facilitera déjà les choses :D

Citation:

Ce que j'ai basculé dans le nouveau projet est juste la partie données. Une fois cette gestion corrigée, il me restera à re-concevoir l'IU.
Je 'ai bien sur déjà essayé de réécrire complètement 'from scratch', mais je suis trop imprégné du modèle que j'avais choisi, et je n'arrive jamais à un truc réellement fonctionnel. Du coup je me suis dit qu'il serait plus simple de partir de ce qui existe. Mon objectif est ici simplement de le faire fonctionner, et ensuite de le faire évoluer.

Ce n'est absolument pas exclu, s'il ne reste que "quelques points" où la VCL s'accroche désespérément :D

Citation:

Je vais voir pour le mettre sur un serveur Git ou autre pour le partager. Cela dit, je n'ai jamais fait cela, et il va me falloir un petit temps.

A vrai dire, c'est "relativement" facile:
tu télécharge et tu installe git
- tu crées un compte sur github ou framagit (cf les liens de mon intervention précédante)... Personnellement, je préfère framagit depuis que microsoft a racheté github, mais bon ;)
- tu crée un repository pour ton projet sur le fournisseur de git que tu as choisi
- tu lance la console git, pour y introduire les commandes
- cd <dossier parent de la ou tu veux avoir tes sources> (l'idéal sera peut être de choisir un dossier autre que le dossier qui contient tes sources actuelles ;) )
- git clone <url indiquée lors de la création du repository>, qui va créer un nouveau dossier (s'il n'existe pas) correspondant au nom que tu aura donné à ton projet
- tu copie l'ensemble des fichiers que contient ton projet (code sources et ressources éventuelles) dans le dossier créé par git
- dans la console git:
  - cd <nom du dossier> pour entrer dans le dossier du projet
  - git add --all pour faire connaitre à git tous les fichiers qui existent déjà
  - git commit -m"initial commit (get back original project" qui "validera" les modifications (autrement dit: l'ajout de tous les fichiers) au niveau local
  - git push qui te demandera de t'identifier pour pouvoir envoyer le tout au serveur
- par sécurité : créer une branche de développement :
  - git branch transit (ou n'importe quel nom de ton choix)
  - git checkout transit pour passer dans la branche créée (pas sur que ce soit obligatoire, mais bon)
- après modifications (ajout ou modification de fichiers)
  - git status te permet de voir les modifications qui ont été apportées mais qui n'ont pas encore été commitées
  - git commit <noms de fichiers> -m"message explicatif" pour commit "local"
  - git push pour tout envoyer au serveur
Pour les autres possibilités, faudra que tu te farcisse le tuto ad-hoc ;)

Citation:

En fait, je cais plutôt le mettre en PJ dans un 7z. Voici le lien Pièce jointe 432021.

C'est aussi une possibilité, en attendant mieux :D

Citation:

J'espère que vous serez indulgents, presque tous mes choix étaient déjà discutables à l'époque. En particulier il y a un peu trop d'interdépendances entre les modules (raison pour laquelle je n'arrive pas vraiment à tester séparément).

Toujours :D Mais indulgents ne veut pas dire complaisants : on ne laissera pas passer d'erreurs sans te la signaler et te l'expliquer (au besoin) :D

Citation:

De plus, comme c'était du code qui n'était pas destiné à être partagé, il est assez peu commenté.

Quoi, tu n'est pas au courant:question:
En dehors des cartouches et d'éventuels commentaires didactiques (pour ceux qui écrivent des cours et des tutos), les commentaires sont à bannir du code... Ca tombe bien, non :question:

Citation:

Je ne suis qu'un simple amateur, sans aucune prétention par rapport à la qualité de son code (raison supplémentaire de ma réticence à partager)...

Nous en sommes bien conscients :D

En même temps, ce devrait au contraire être ... une raison de plus pour t'inciter à partager ton code!!!

Car, c'est en le partageant avec des gens qui ont (ou non) "plus l'habitude que toi" et qui pourront t'indiquer les erreurs que tu apprendra le plus ;) (cela s'appelle "la revue par les pairs")

Je suis très embêté, car tu as oublié de rajouter le fichier date.h (et donc, sans doute aussi le fichier date.cpp) dans ton archive, ce qui fait se vautrer le compilateur :P

Quelques notes au passage:

1- Evite définitivement les macros, car ils posent plus de problèmes qu'ils n'apportent de réelles solutions ==> Why macros are evil<== (n'hésite pas à suivre les liens #1, #2, #3 et #4

2- Sois attentif, lorsque tu n'utilises pas les accolades pour englober les blocs d'instructions, à respecter scrupuleusement l'indentation!

Un code tel que
Code:

1 2 3 4 5 6 if (champ.EstValide()) return suivant->Evaluer(*champ,args); const TBaseTable &table=TBaseOrientation::Base()->Table(Type()); const TEnregistrement &enreg=table[champ]; return suivant->Evaluer(enreg,args);
laisse vraiment planer un doute affreux sur tes intentions, car
les règles du C++ veulent que seule la ligne suivant-Evaluer(*champs, args);
l'indentation laisse à supposer que tu pourrais t'attendre à ce que les quatre lignes soient soumises à la condition

(une chance que la première ligne impliquée contient une instruction return, qui lève tout à fait le doute quant à tes intentions ;) )

3- Typiquement, les classes qui interviennent dans une hiérarchie de classes (qui servent soit de classe de base dans un héritage, ou qui héritent d'une classe de base) sont des classes qui ont sémantique d'entité:

-La comparaison entre deux instances différente de la même classe n'a pas de sens : tu peux comparer (certains de) leurs états séparément, mais chaque instances est -- par nature -- strictement unique ;)
-La copie n'a absolument aucun sens, le clonage n'en a que très rarement (et je serais d'avis que le clonage de tes classe n'a aucun sens dans le cas des classes que tu as créées)

4- on trouve des new, des new[], des delete et des delete[] dans plusieurs fichiers... C'est une très mauvaise idée!!! que penserais tu d'utiliser std::unique_ptr ou std::shared_ptr (avec une nette préférence pour le premier) :question:

5- l'usage du transtypage (dynamic_cast en particulier) est généralement le symptôme par excellence que l'on est passé "à coté de quelque chose":

Si on l'utilise sous forme de test, cela signifie surement que l'on a été "assez bête" que pour perdre le type réel de la donnée "en cours de route"

Si on l'utilise de manière "inconditionnelle", cela implique sans doute que l'on utilise un type inadapté pour maintenir le lien vers une donnée particulère :P

Quoi qu'il en soit, il y a moyen de faire bien plus simple, sécurisant et, sans doute, bien plus efficace ;)

Et il y aurait encore bien d'autres remarques à faire, mais je vais déjà te laisser digérer celles là ;)

04/12/2018, 18h48
Teaniel

Re :)

Ben... J'ai envie de dire merci pour le cours, et toutes les autres infos :) je mets tout ça tout de suite en pratique.

@Luc : AdressSanitizer -> J'ai vite fait un tour sur le net, ça a l'air prometteur. Pourrait bien être la réponse directe à ma question initiale. Merci!

@bacelar : Comme je suis sous QT Creator, j'ai des kits de compilation préréglés. Cependant je vérifierai ces réglages, car c'est vrai que le mode de debug n'est pas très bavard... Concernant les warning, j'applique déjà ta maxime. Et je résous tous les warnings quand c'est possible (mon projet compile actuellement avec un seul warning concernant un break manquant dans un switch/case, que je ne mettrai pas) Cela dit je vérifierai également de ce côté là.

@Koala01 : Merci pour tes encouragements! et je passerai mon code sur Git aussitôt que possible (ce soir donc). Ça m'obligera en même temps à le nettoyer un peu mieux que ce que j'ai fait (il est vrai à grande vitesse avant de partir au boulot ce matin) avec le zip. Génial ce tuto! me permettra de démarrer et même un peu plus! J'indiquerai le lien un peu plus tard.

Merci à tous,
et à bientôt!
Marc
04/12/2018, 20h37
Teaniel

1 pièce(s) jointe(s)

@Koala01
Désolé, nous avons à nouveau écrit en même temps ;)

Citation:

Je suis très embêté, car tu as oublié de rajouter le fichier date.h (et donc, sans doute aussi le fichier date.cpp) dans ton archive, ce qui fait se vautrer le compilateur

Oups!
En fait il s'agît de la bibliothèque date.h de Howard Hinnant, qui complète <chrono> avec des fonctions de stream etc... Il n'y a qu'un seul et unique fichier (note qu'il a demandé un passage de son travail au standard, le lien pointe sur sa description). C'est assez impressionnant comme elle m'a permis de réduire le code lié au temps. En pj le contenu du dossier d'install (il a une deuxième bibliothèque pour la gestion des timezones)Pièce jointe 432185. ¨Pour ma part je l'ai mis à part près des include de QTCreator.

Citation:

1- Evite définitivement les macros

J'en ai bien conscience. Pour l'instant j'en garderai une grande partie (pour l'instant seulement bien sur) car elles m'ont permis de diviser la taille de mon code par 5 ou 6 à une époque où il n'y avait que très peu de template possibles. A terme, tout le code en macro sera remplacé par des template quand ce sera possible, sinon réorganisé. A l'époque, le maître mot en programmation était 'Encapsulation'. C'est pourquoi j'aimais bien le concept de propriétés de BCB (on accède à une propriété avec '.' et les getter / setter sont cachés, ce qui permet de les remplacer par un accès direct ou un autre calcul sans changer la syntaxe). Et flemmard que je suis, je trouvais plus joli d'écrire objet.champs.champs.champs, plutôt que objet.getChamps().getChamps().getChamps().

Citation:

2- Sois attentif, lorsque tu n'utilises pas les accolades pour englober les blocs d'instructions, à respecter scrupuleusement l'indentation!

C'est normalement ce que je fais, mais les éditeurs mettent parfois des tab où je veux indenter (plusieurs versions de bcb sont passées par là, pas toujours configurées pareil), et comme j'utilise un pas de 4 normalement, ça peut fausser le jeu. Désolé si c'est le cas ici (il y en avait beaucoup que j'ai déjà corrigé. il doit surement en rester un peu). Je le fais d'autant que je trouve moche un code indenté de travers, en plus des erreurs de lecture que ça peut engendrer.

Citation:

3- Typiquement, les classes qui interviennent dans une hiérarchie de classes (qui servent soit de classe de base dans un héritage, ou qui héritent d'une classe de base) sont des classes qui ont sémantique d'entité

Et c'est là que commence la vraie refonte de mon (vieux) code. Dans la mesure où, tel que, il a fonctionné (et fonctionne toujours), je pense assumer ces incohérences pour l'instant et y travailler ensuite. Possible que j'aie tort, mais j'ai le sentiment qu'il me sera plus facile de corriger un code que je sais fonctionner (en gros une chose à la fois).

Citation:

4- on trouve des new, des new[], des delete et des delete[] dans plusieurs fichiers... C'est une très mauvaise idée!!! que penserais tu d'utiliser std::unique_ptr ou std::shared_ptr (avec une nette préférence pour le premier)

Noté. Petit détail : ces concepts n'existaient tout simplement pas à l'époque (apparus avec c++03 et boost de mémoire). Donc cela fera partie de la refonte à venir.

Citation:

5- l'usage du transtypage (dynamic_cast en particulier) est généralement le symptôme par excellence que l'on est passé "à coté de quelque chose":

Tu as surement raison, et je vais évidemment suivre ton conseil.
Cela dit, je devrai sans doute refaire appel à ce forum le moment venu, car même pour l'instant je ne suis pas sur de savoir comment corriger cela.

Citation:

Et il y aurait encore bien d'autres remarques à faire, mais je vais déjà te laisser digérer celles là

:aie::aie: Je te remercie! lol je me disais bien que tout ça ne serait pas gratuit! :aie:
Va me falloir du temps. Comme tu peux le constater, il y a des choses que je sais déjà, d'autres que je découvre.
Beaucoup de lecture et d'études en perspectives.

Tu as toute ma reconnaissance pour le travail que tu fais pour moi. C'est vraiment très sympa!
J'espère pouvoir un jour te rendre la pareille!
Merci à toi, et aux autres aussi.

A bientôt,
Marc

Citation:

Envoyé par Teaniel

Oups!
En fait il s'agît de la bibliothèque date.h de Howard Hinnant, qui complète <chrono> avec des fonctions de stream etc... Il n'y a qu'un seul et unique fichier (note qu'il a demandé un passage de son travail au standard, le lien pointe sur sa description). C'est assez impressionnant comme elle m'a permis de réduire le code lié au temps. En pj le contenu du dossier d'install (il a une deuxième bibliothèque pour la gestion des timezones)Pièce jointe 432185. ¨Pour ma part je l'ai mis à part près des include de QTCreator.

Du coup, ca compile tout de suite beaucoup mieux :D

Citation:

J'en ai bien conscience. Pour l'instant j'en garderai une grande partie <snip>

Et c'est là que commence la vraie refonte de mon (vieux) code. Dans la mesure où, tel que, il a fonctionné (et fonctionne toujours), je pense assumer ces incohérences pour l'instant et y travailler ensuite. Possible que j'aie tort, mais j'ai le sentiment qu'il me sera plus facile de corriger un code que je sais fonctionner (en gros une chose à la fois).

ces concepts n'existaient tout simplement pas à l'époque (apparus avec c++03 et boost de mémoire). Donc cela fera partie de la refonte à venir.

Je comprends parfaitement ton point de vue, ne va surtout pas croire le contraire ;)

Mais, je crois, sincèrement que, en l'occurrence, tu as tord sur ce coup là.

Tu veux -- et c'est bien normal -- moderniser un projet qui a fonctionné pendant des années. Mais je crois que, au point où tu en es, tu vas perdre beaucoup plus de temps (et de cheveux !!!) à vouloir corriger les choses les unes après les autres en te disant "ca, je vais laisser sur le coté pour la suite".

Ne serait-ce que, parce que si j'ai bien compris l'idée de ce projet, c'était de disposer d'une "sorte de base de donnée perso". Et cela peut se comprendre quand on sait à quels choix nous étions contraints à l'époque : entre access et les SGBDR "classiques" (allant de MySQL à Oracle, en passant par MsSql), cela aurait pu te donner l'impression d'avoir à choisir entre la peste et le choléra ;)

Mais, sais tu que Sqlite, par exemple, fournit désormais un système de base de données particulièrement cohérent, léger, gratuit, opensources et que Qt fournit très gracieusement "tout ce qu'il faut" pour pouvoir manipuler ce genre de base de données "à son aise" :question: (pour information : c'est le système de base de donnée qui se cache derrière Thunderbird :P)

De plus, j'ai l'impression que tu t'es beaucoup trop enfoncé dans une approche "tout oo", bien que je comprenne les raisons qui t'ont poussé à agir de la sorte, je crois que le fait d'élargir directement tes horizons pourrait te faciliter énormément la vie.

Par exemple, tout ton dossier CHAMPS pourrait allègrement se résumer à quelque chose qui serait proche de
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 /*désolé, mais j'ai trop l'habitude de prendre des noms anglais */ template <typename T, bool Convertible> struct Strignifier; /* il y aura quelques spécialisations (pour std::string, notamment) à ajouter par la suite ;) */ template <typename T, struct Strignifier<T, true>{ std::string std::string toString(T const & v) const{ return std::to_string(v); } }; template <typename Type, bool StringConvertible = std::is_arithmetic_v<Type> || std::is_same_v<std::string, Type> || std::is_same_v<std::wstring, Type>> struct Field{ using strignifier_type = Stringifier<Type, StringConvertible>; Field(std::string const & n):name{n}{ } std::string const name; Type value; }; template <typename T> inline bool sameName(Fied<T> const & f, std::string const & name){ return f.name == name; } template <typename T, typename U, typename = std::enable_if<std::is_same_v <T, U>::type> bool operator = (Field <T> const & f, U const & test){ return f.value == test; }
pour les enregistrement, nous pourrions avoir recours au CRTP sous la forme de
Code:

1 2 3 4 5 6 7 template <typename T> struct RecordBase{ Field< IdType > id{"Id"}; }; template <typename Fields> struct Record : public RecordBase<Fields>, public Fields{ };
Ce qui nous permettrait de définir un enregistrement sous une forme proche de
Code:

1 2 3 4 5 6 7 8 struct AddressFields{ Field<std::string> street{"Street"}; Field<int> number{"Number"}; Field<std::string> zipCode{"ZipCode"}; Field<std::string> locality{"Locality"}; Field<std::string> town{"Town"}; }; using AddressRecord = Record<AddressFields>;
Dis toi bien que, à partir du moment où tu passe ton temps à jouer avec des accesseurs et des mutateurs, il n'y a plus aucune raison de s'amuser à placer les données dans l'accessibilité privée: nous sommes avons tout aussi vite fait (en réalité, nous avons beaucoup plus vite fait :D ) de les garder dans l'accessibilité publique, quitte à s'arranger pour rendre le type totalement opaque pour l'utilisateur, et à lui fournir une série de fonctions qui permettront d'éviter au mieux les problèmes. Je t'expliquerai "plus tard" comment t'y prendre, si tu en émet le souhait ;)

Et, à partir de là, tu pourrais même créer une classe template sous une forme proche de
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 template <typename Rec> class Table{ using set_t =std::set<Rec, [&](Rec const & a, Rec const & b){return a.id<b.id;}>; public: Table(std::string const & name):name_{name}{ } size_t size() const{ return records_.size(); } void add(Rec const & r){ records_.insert(r); } /* ... */ private: set_t records_; }
Et, tout ce qu'il te faudra pour créer toutes les tables que tu veux se limitera à:
une struture que tu définis toi meme pour représenter un enregistrement dans la table et
un alias de type sur la spécialisation de Table pour le type d'enregistrement en question.

En 53 lignes de code, je viens de te permettre de virer une grosse partie des 32 fichiers qui se trouvent dans le dossier CHAMPS et de limiter très sérieusement le code des fichiers qui se trouvent dans les dossier Enregistrements et TABLE

Alors, bien sur, il manque pas mal de truc! Mais ne crois tu pas que cela vaudrait effectivement la peine de partir d'une feuille blanche :question:

(au passage, voici un petit projet qui pourrait t'être bien utile dans l'approche DOD ;) )
WARNING
Le code présenté ici a été écrit "à la volée" et n'a donc absolument pas été testé (honte à moi :P )

Si je ne me suis pas trompé, il devrait fonctionner. Mais il se peut tout aussi bien qu'il ne compile même pas sans certaines modifications ;)

05/12/2018, 16h53
bacelar

En plus des conseils plein de claire-voyance de @koala01, il est aussi possible de mettre en place, avec des framework dédiés aux tests, les tests de non-régression qui permettra d'être bien plus confortable pour le refactoring qui s'impose.
Le fait d'avoir séparé la partie graphique de la partie métier permettra de conserver ces tests même après le passage à Qt comme bibliothèque graphique.
05/12/2018, 19h00
Teaniel

Bonjour,

@Koala01 : Je suis un peu bluffé par la rapidité de ton analyse. Je pense que tu as surement raison.

Citation:

Tu veux -- et c'est bien normal -- moderniser un projet qui a fonctionné pendant des années.

C'est effectivement mon idée, et j'en comprends également les implications (de mieux en mieux même lol). Cela dit, le temps, tu as dû te rendre compte, je l'ai déjà perdu (Quand à mes cheveux... Plus de risque de ce côté là...). Le code que je t'ai fourni est déjà presque fonctionnel: Il compile complètement et il subsiste simplement (s'il n'en masque pas d'autres) le bug qui a motivé ce post. Ce n'est que dans ce délai que je reporte mon analyse. J'aurais dû le dire plus tôt je m'en rends compte maintenant, mais champs et enregistrements ont été testés individuellement (main() en contient encore le code).
En fait, il s'agît bien d'une migration, car je souhaite reprendre toutes les données que j'ai conservées depuis ces années, les mettre également au goût du jour (Certaines données en trop, et d'autres à réorganiser).
Et puis bon, ça me fait aussi plaisir de voir que mon code fonctionne encore avec C++17, presque sans retouche. Je pense même que ce n'est pas loin d'être la raison principale (narcissique vous avez dit?).

Citation:

Ne serait-ce que, parce que si j'ai bien compris l'idée de ce projet, c'était de disposer d'une "sorte de base de donnée perso". Et cela peut se comprendre quand on sait à quels choix nous étions contraints à l'époque : entre access et les SGBDR "classiques" (allant de MySQL à Oracle, en passant par MsSql), cela aurait pu te donner l'impression d'avoir à choisir entre la peste et le choléra

Tu ne crois pas si bien dire. :aie:
Sérieusement, j'ai une raison pratique d'en rester aux fichiers plats : Mes 'clients' et amis qui sont appelés à utiliser ce programme ne sont pas informaticiens. Le programme et le fichier qui l'accompagne (actuellement ça prend cette forme) circulent d'ordinateur en ordinateur, bien souvent sans même quitter la clé, et doivent pouvoir être manipulés hors de ma présence. Tout cela en pleine nature (au bord de plans d'eau pour être précis). Pour l'instant, je conserve cette contrainte forte : Zéro install et le moins de fichiers possibles. Je pense que ça ne laisse pas beaucoup de choix... Les webservices, j'y réfléchirai plus tard.

Citation:

De plus, j'ai l'impression que tu t'es beaucoup trop enfoncé dans une approche "tout oo", bien que je comprenne les raisons qui t'ont poussé à agir de la sorte, je crois que le fait d'élargir directement tes horizons pourrait te faciliter énormément la vie.

Là je me fais juste l'impression d'être un vieux croulant :aie:.
En effet, à cette époque, on ne pensait que oo. Tout était objet, et tous les mécanismes de mon programme y sont soumis. Ce sont des objets qui parlent à d'autres objets. En plus on ne savait pas les factoriser autrement qu'en utilisant des macros. Ça avait également l'avantage de fournir une certaine lisibilité (on peut assez facilement - si c'est bien conçu - connaître les responsabilités de chacun), et j'ai encore de la littérature qui parle de réification, c'est à dire de représentation de la réalité en OO (ça a abouti à UML). A la réflexion, c'est vrai qu'au fil du temps j'ai plus appris à réfléchir Objets que C++ (j'ai aussi utilisé UML pendant un temps)...

Citation:

Et, tout ce qu'il te faudra pour créer toutes les tables que tu veux se limitera à:

une struture que tu définis toi même pour représenter un enregistrement dans la table et
un alias de type sur la spécialisation de Table pour le type d'enregistrement en question.

Je prends. Et ton code m'intéresse particulièrement. Merci beaucoup !
Deux ans de réflexion et de codage (et 8 ou 9 d'entretien) résumés en 65 lignes de code... :aie::aie: Vexant tout de même un peu... Heu... 53... Encore pire!
(:humour: évidemment!)

Je vous remercie tous pour votre implication!
Je vais maintenant me concentrer un peu sur la résolution de mon souci du début, tout en pensant aux soucis qui m'attendent...

A bientôt,
Marc
07/12/2018, 01h06
Teaniel

Bonjour,

Je viens de trouver le coupable.
En fait, c'est un problème que j'ai introduit au moment de la correction d'un des sources (TEnregistrementClassement), qui initialisait plusieurs attributs de type TChampsCalcule avec nullptr (c'est moi qui ai interprèté la valeur d'initialisation 0, qui était acceptable, en nullptr, qui l'était beaucoup moins :calim2:. Je me demùande ce que j'avais bu ce soir là...).
Ce que j'ai du mal à comprendre, c'est que aucun constructeur de la classe TChampsCalcule n'accepte un pointeur comme seul argument. J'aurais dû me faire insulter par le compilateur.
Pour arriver à ce résultat, j'ai simplement changé de version de MinGW (passé à QT5.12 et le compilo en MinGW 3.7 64b) comme ça j'ai effectivement C++17 et 64b, ce que MinGW 5.3 32 ne me permettait pas. Avec cette version, le point d'arrêt que j'avais placé sur la ligne throw de _M_Construct a fonctionné, et je suis arrivé à mes fins.
Merci à tous pour vos conseils et votre patience.
@Koala01 je vais sans doute revenir vers toi concernant le code que tu m'as donné. Actuellement je cherche à le comprendre et je vais peut-être avoir besoin de ton aide pour cela, si tu le veux bien évidemment (le moins qu'on puisse dire est que je ne suis pas familier des classes trait). C'est pourquoi je laisse le sujet ouvert.

Encore merci
A bientôt,
Marc
09/12/2018, 19h53
koala01

1 pièce(s) jointe(s)

Citation:

Envoyé par Teaniel

Je prends. Et ton code m'intéresse particulièrement. Merci beaucoup !
Deux ans de réflexion et de codage (et 8 ou 9 d'entretien) résumés en 65 lignes de code... :aie::aie: Vexant tout de même un peu... Heu... 53... Encore pire!
(:humour: évidemment!)

Y a pas de quoi être vexé!!! Tu sais, je vis C++ depuis plus de quinze ans maintenant, en veillant à me tenir à jour :P

Il est donc "dans l'ordre des choses" que je m'y connaisse "un tout petit peu", et que je puisse trouver des solutions auxquelles tu n'aurais sans doute pas pensé ;)

En outre, j'ai eu mauvaise conscience à te fournir un code si crapuleusement non testé. Je me suis donc amusé à faire quelque chose de correcte. Et, comme je sais que tu utilises QtCreator, j'ai veillé à fournir la gestion du projet sous la forme "native" utilisée par cet EDI ;)

Je te présente Pièce jointe 433185 (pour Easy Multi Record Holder). Il y a encore plein de chose à rajouter pour que cela puisse effectivement devenir utilisable, mais tu devrais avoir beaucoup plus facile à le comprendre ;)
11/12/2018, 07h39
Teaniel

Bonjour,

Désolé pour la réponse tardive, hier matin j'en ai commencé une, et j'ai malencontreusement fermé le navigateur au lieu de poster... (début de dmla? :aie:)
Ce matin j'ai voulu reprendre le fil, et je n'ai pas pu recherger le brouillon. Les sauvegardes automatiques ne sont elles pas conservées un temps?

Ceci étant, merci, vraiment pour ton aide.
J'ai évidemment commencé par télécharger ton code, et à le regarder, et à chercher à le comprendre.
Je reviendrai vers toi (ici, je veux dire ;)) avec les questions auxquelles je n'aurai pas trouvé de réponse.

Citation:

Y a pas de quoi être vexé!!!

Oublie pas

Citation:

(:humour: évidemment!)

, c'était simplement une façon de marquer mon admiration.

Je me permets de revenir un peu en arrière :

Citation:

En dehors des cartouches et d'éventuels commentaires didactiques (pour ceux qui écrivent des cours et des tutos), les commentaires sont à bannir du code... Ca tombe bien, non

J'espère que j'interprète bien, mais je ne suis pas vraiment d'accord : J'aurais bien pris quelques lignes d'explication dans mon code pour déverminer plus facilement les fonctions d'E/S de mon programme, et quelques autres que je vais avoir à reprendre. Tant que tu es plongé dans ton trip, tout est toujours clair. Mais laisse reposer quelques mois, et tu te retrouves à te poser mille fois la question : Mais qu'est-ce que j'ai bien pu vouloir faire là? Si comme moi il y a quelques jours, tu ne peux en plus pas débugger le mécanisme (en raison d'autres erreurs), alors t'es coincé.
Perso, je pense essayer d'en rajouter un peu.
A ce propos, dans ToStringConverter.hpp il semble qu'il y ait un language de description dans les commentaires. Je ne le connais pas. Serait-il possible de connaître l'outil que sait lire ça (je suppose que c'est celui qui a été utilisé pour générer le site CppReference).

Encore merci pour votre aide à tous!
Surtout à toi Kopala01

à bientôt,
Marc

Citation:

Envoyé par Teaniel

J'espère que j'interprète bien, mais je ne suis pas vraiment d'accord : J'aurais bien pris quelques lignes d'explication dans mon code pour déverminer plus facilement les fonctions d'E/S de mon programme, et quelques autres que je vais avoir à reprendre. Tant que tu es plongé dans ton trip, tout est toujours clair. Mais laisse reposer quelques mois, et tu te retrouves à te poser mille fois la question : Mais qu'est-ce que j'ai bien pu vouloir faire là? Si comme moi il y a quelques jours, tu ne peux en plus pas débugger le mécanisme (en raison d'autres erreurs), alors t'es coincé.

Crois bien que je comprend ton point de vue, mais je peux t'assurer que, d'une certaine manière, les commentaires qui ne font pas partie des deux catégories que j'ai citées (cartouches et commentaires à visées didactiques) posent bien plus de problèmes qu'ils n'en résolvent.

Car les commentaires ne sont purement et simplement pas analysés par le compilateurs, Si bien que nous pouvons y mettre ce que nous voulons (y compris les conneries les plus ineptes), nous ne serons jamais contredit.

Or, dans le code, la seule chose qui compte réellement, la seule chose qui soit prise en compte par le compilateur, c'est le code, et rien que le code. Si on rajoute des commentaires, nous offrons à "l'un des destinataires du code" (le type qui lira le code) une "autre source d'informations", qui n'est absolument pas prise en compte par l'autre destinataire du code (le compilateur).

Mais cerveau humain est bien fait : en présence de deux sources d'informations distinctes (le code et les commentaires), il va "naturellement" privilégier la source qui lui demandera le moins de travail pour être comprise. C'est à dire qu'il privilégiera systématiquement ... les commentaires.

Le gros problème, c'est que le code, c'est quelque chose de "vivant"! Tant que l'on n'a pas décidé de mettre un "point final" au projet, le code aura de bonnes raisons de changer et / ou d'évoluer.

Mais je parle bien du code quand je dis que cela évolue !!! Pour ce qui est des commentaires:

ou bien on oublie de les mettre à jour
ou bien on n'ose pas trop y toucher (même si on en est l'auteur original)
on a naturellement tendance à les lire, et à ignorer purement et simplement le code qu'ils expliquent.

Et le risque est alors de se retrouver avec des commentaires qui n'ont absolument rien à voir avec le code qu'ils sont sensés expliquer.
Nous sommes donc face à deux sources d'informations totalement désynchronisée, et dont le malheur veut que notre attention sera attirée (et captée) en priorité par ... celle qui ne correspond (peut-être) plus à la "réalité du moment" (au code tel qu'il sera exécuté réellement).

Au final, on en arrive à croire que "quelque chose" (qui a été expliqué par les commentaires) sera exécuté, alors que c'est ... autre chose (le code) qui est effectivement exécuté. Et on s'étonne de ne plus comprendre ce qui se passe!!!!

Citation:

Perso, je pense essayer d'en rajouter un peu.

Oui, quelque commentaires sont parfois utiles : ce sont les cartouches, car il donnent une explication sur la manière dont tu remplis un besoin donné. Je m'explique:

Que tu décide de créer une fonction -- qu'il s'agisse de fonctions libres ou de fonctions membres ("méthode") de classe -- ou un type de donnée (qu'il s''agisse d'un alias de type, d'une classe, d'une structure, d'une union ou d'une énumération), tu le fais parce que tu as identifié un besoin que tu veux remplir.

A partir du moment où un besoin est désigné, il restera nécessaire de le remplir "jusqu'à la fin des temps", vu que le fait de rencontrer ce besoin est l'un des buts de ton projet.

S'il s'agit d'un type de donnée, n'aie pas peur de dire à quel usage il sera dédié, d'exprimer ce qu'il permet de représenter, par exemple :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 /* représente la durée (jour, mois, année, heure, minutes secondes) * pendant laquelle une action ou un événement donné sera exécuté */ class Duration{ /* ... * Pour chaque fonction publique, une petite explication de * ce à quoi elle sert, des paramètres requis et de la valeur * renvoyée sera intéressante */ }; /* permet de savoir si une année est bissextile * * une année est bissextile si sa valeur est divisible par 4 , * sans être divisible par 100 ou en étant divisible par 400 * * paramètre : année l'année qui doit être testée * * Renvoie "vrai" si l'année indiquée est bissextile, "faux" * dans le cas contraire */ bool estBissextile(int annee){ /* ...*/ }
De tels commentaire resteront vrais en permanence, quel que puisse être le contenu de ma classe Duration ou de ma fonction estBissextile.

Pourquo :question: Simplement parce que, à partir du moment où j'ai identifié le fait que j'avais besoin d'une donnée permettant de représenter les durées ou d'une fonction me permettant de savoir si l'année est bissextile ou non, je peux être sur que je vais commencer à ... utiliser cette donnée ou cette fonction.

Et je peux être sur que, dans dix ou dans vingt ans, j'aurai toujours besoin de pouvoir représenter une durée ou d'être en mesure d'évaluer si une année est bissextile.

Je me fous pas mal de savoir comment ces éléments sont implémentés (quoi que je devrais sans doute indiquer une interface qui permettrait d'obtenir les services de bases dont j'estime avoir besoin pour traiter les durées)!! je sais que, vu que j'ai eu "un jour" besoin de cette donnée et de cette fonction, j'en aurai toujours besoin .

Mais je n'ai pas créé cette classe ou cette fonction pour moi!!! je l'ai créé pour celui qui viendra "après moi", pour celui qui... aura besoin de l'utiliser, et qui devra donc savoir... comment l'utiliser correctement.

Bon, d'accord! Il se peut tout à fait que celui qui devra l'utiliser ne soit personne d'autre que moi, dans deux jours, dans un mois ou dans dix ans. Bref, dans un délais largement suffisant que pour m'avoir permis d'oublier tous les "détails sordides" de la logique que j'ai mise en place pour rendre les services attendus :P

Mais si je dois utiliser ce type de donnée ou cette fonction "plus tard", je m'en foutrai pas mal de ces détails sordides : je partirai du principe que j'ai fait du bon travail lorsque j'ai défini cette classe et cette fonction, et qu'elles font exactement ce pour quoi elles ont été créées à la base.

Les seules choses que j'aurai réellement besoin de savoir, c'est : comment est-ce que je dois les utiliser :question: quels paramètres dois-je fournir:question: dans quel ordre :question: qu'est ce que j'obtiens en retour :question:

Tous les autres commentaires, du genre de
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 bool estBissextile(int annee){ /* vérifie si l'année est un multiple de 4 */ if(annee % 4 == 0){ /* vérifie si l'année est un multiple de 100 */ if(annee % 100 == 0){ /* ne renvoie vrai que si l'année est un multiple de 400 */ return annee % 400 == 0; } return true; } /* si l'année n'est pas multiple de 4, elle n'est pas bissextile */ return false; }
ne feront qu'une seule et unique chose : paraphraser le code.

Car, soyons bien clair : ce que j'ai indiqué dans mes commentaires correspond -- pour l'instant -- exactement à ce que le code fait.

Sauf que, dans quelques mois, je vais trouver une autre logique pour faire la vérification, qui prendra trois fois moins longtemps à s'exécuter!!!

Mes commentaire ne serviront donc plus à rien et, pire encore! ils exprimeront peut être une logique qui n'a absolument rien à voir avec le code !!!

Ce genre de commentaire n'a rien à faire dans un code "de production". Au mieux, je pourrai les écrire si je veux présenter mon code à des étudiants débutants pour qu'ils comprennent la logique mise en oeuvre. Mais, même si ce n'est qu'un stagiaire dans sa première semaine de stage, je suis malgré tout en droit d'espérer que mon stagiaire connaît un minimum le C++ quand il vient travailler sur mon projet!!!

Je suis quand même en droit de partir du principe que toute personne posant les yeux sur mon code en saura suffisamment sur le langage que j'utilise pour savoir ce que représente la formule x % y == 0. Pourquoi devrais-je me faire ch...er à l'exprimer autrement :question:

Par contre, j'ai une espèce d'obligation morale qui consiste effectivement à rendre mon code "aussi compréhensible que possible". Car j'aurai très bien pu écrire un code proche de
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 /* oui, ce code fonctonne !!! */ #include <iostream> #include <ios> #define _ bool #define __ int _ ___(__ _____){ return _____ % 4 == 0 ? _____ % 100 == 0? _____% 400== 0 :true :false; } int main(){ std::cout<<"1000 est bissextile ? "<<std::boolalpha<<___(1000)<<"\n" <<"2000 est bissextile ? "<<std::boolalpha<<___(2000)<<"\n" <<"2018 est bissextile ? "<<std::boolalpha<<___(2018)<<"\n" <<"2020 est bissextile ? "<<std::boolalpha<<___(2020)<<"\n"; }
Mais tu avouera que, bien que le code fonctionne, il est très loin d'être particulièrment compréhensible ;)

Les quatre armes dont je dispose sont :
une mise en forme stricte : une instruction par ligne, ni plus ni moins
une indentation stricte : chaque bloc d'instruction est "décalé" par rapport au bloc d'instruction qui le contient
une politique de nommage qui permettra au lecteur de comprendre l'utilité de quelque chose grâce au nom qui lui a été donné
une politique de "casse" des noms choisi suivie scrupuleusement

Je n'ai besoin de rien d'autre pour me faire comprendre! Et surement pas de commentaires ;)

Citation:

A ce propos, dans ToStringConverter.hpp il semble qu'il y ait un language de description dans les commentaires.

Bien vu!!!

Citation:

Je ne le connais pas. Serait-il possible de connaître l'outil que sait lire ça

Il s'agit de doxygen, un outil qui permet d'extraire la documentation à partir du code sources

Citation:

(je suppose que c'est celui qui a été utilisé pour générer le site CppReference).

Non, sauf erreur, cppReferences est écrit en markdown :P
à bientôt,
Marc[/QUOTE]

11/12/2018, 19h27
Teaniel

Re :)

Il semble que nous pensions à peu près pareil. Ce que je voulais dire était bien 'une petite explication à l'entête de la fonction, éventuellement un mot à l'intérieur pour expliquer, non le comment, mais surtout le pourquoi de certaines constructions ou mécanismes un peu trop complexes, permettant d'en accélérer la compréhension'. Il n'est absolument pas dans mon ambition de commenter un getter... Inutile et insultant pour le lecteur...
Sauf que toi tu dis 'ne pas commenter' et moi l'inverse, et ce que nous faisons est au milieu... J'ai fait deux erreurs, pendant la reprise, qui ont amené des plantages parce que je n'avais pas compris la mécanique mise en place dans un appel de fonction (je devais transmettre une référence à un pointeur, ce que je n'ai pas vu et remplacé par le pointeur déréférencé (aussi un pointeur), enfin un truc pas bien quoi. Là, un petit commentaire m'aurait économisé quelques passes de débugger pour comprendre.
Merci pour tes explications.

J'ai bien compris la nécessité du caractère immuable des commentaires.
Je vais voir un peu du côté de Doxygen, la syntaxe a l'air assez intuitive (si les commentaires doivent être immuables alors il est bon que ceux qui restent utiles soient formatés de telle sorte qu'un outil de documentation puisse les extraire).

Je crois que la chose la plus importante que j'ai (re)comprise pendant ce post est que C++ est un langage, c'est à dire un ensemble d'outils (class = outil, template = outil, //, etc...), qui servent à l'humain à expliquer à une machine ce qu'il veut qu'elle fasse, et donc à ce titre, il est vital que l'assemblage utilisé de ces outils soit compréhensible par les deux parties.
Tout extrémisme dans l'usage (ou pas) de ces outils se terminera par une baisse de l'efficacité du résultat.

Encore merci à toi :)

A bientôt
Marc
13/12/2018, 18h56
bacelar

J'approuve complètement @Koala01, les commentaires inutiles, c'est caca.
Et les commentaires sont dans la très grande majorité des cas totalement inutiles.

Si vous avez besoin de commentaire pour faire comprendre comment se servir d'une API et que l'API permet de facilement mal l'utiliser, c'est que l'API a un problème.

Pour votre exemple, la signature de l'API, et particulièrement, le typage des paramètres aurait dû interdire cette "confusion" (mauvais usage).