Discussion :

[Teaniel]

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

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

[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

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

[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

[koala01]

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

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

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

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

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

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

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

Le bénéfice me semble -- pour potentiel qu'il puisse être -- largement supérieur au risque encourru! Qu'en penses tu

[Teaniel]

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

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

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

[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!