Coucou ça faisait longtemps que j'étais pas venue ici, c'est tout simplement parce que j'ai pris conscience de quelque chose, vous avez le droit de préférer le C++ moderne et vous avez aussi le droit d'être dans l'erreur donc si j'arrive pas à vous convaincre c'est pas grave
Mais je dois quand même vous dire quelque chose, le debugger de Visual studio n'est pas seulement lent, il est en plus bugué, car quand on tombe sur une exception ou autre et qu'on remonte la call stack, il se met sur l'instruction d'après donc on peut plus inspecter les variables du scope https://twitter.com/cmuratori/status/1693338803371737505
Et donc pour remédier à ce problème, nous avons le magnifique RemedyBG qui est tout simplement le meilleur debugger day-to-day pour le C++, je vous avais déjà montré la vidéo où Casey explique pendant 20 minutes pourquoi il est bien mais je vous la remet pour ceux qui l'ont pas vu https://www.youtube.com/watch?v=r9eQth4Q5jg
Connaissant ta totale maîtrise de la mesure @JadeSalina, on va commencez par le préceptes de la dent d'or de Fontenelle : donnes nous un putain de code et une version de VS "trouvable" pour qu'on puisse vérifier tes dires.
Je recherche un CDI/CDD/mission freelance comme Architecte Logiciel/ Expert Technique sur technologies Microsoft.
Connaissant ta totale maîtrise de la mesure @JadeSalina, on va commencez par le préceptes de la dent d'or de Fontenelle : donnes nous un putain de code et une version de VS "trouvable" pour qu'on puisse vérifier tes dires.
Pour faire simple, si il y a une exception throw lors d'un appel de fonction et que cet appel est le dernier du bloc, on ne pourra jamais inspecter les variables dans le bloc puisque visual Studio se met sur la ligne suivante. Pour tester il suffit de prendre un Visual studio sorti après 2005 ils ont tous ce bug. Mais il y a un exemple justement dans un des tweets que j'ai mis vous n'avez pas regardé ? C'est celui ci où on voit le phénomène https://twitter.com/ryanjfleury/status/1693061763884007643 (et juste en dessous on voit le comportement voulu (avec RemedyBG))
dragonjoker a écrit:
Bla bla bla ... Casey ... Bla bla bla ... voici le meilleur <insérer un truc> ...
T'as l'intention de changer de pattern, un jour ?
J'y peux rien si c'est la vérité et que c'est Casey qui nous fait en prendre conscience
Une putain de copie d'écran, tu parles de professionnels en carton plus adepte des polémiques twittesques que de faire avancer la connaissance.
BORDEL.
P.S.: Quand on utilise un débogueur, on parle de "frames" pour un contexte de variables, pas de "Visual Studio se met sur une ligne", qui ne veut strictement rien dire de concret.
Déjà, sur la forme du machin, ça sent pas la rose mais un bug à 2 balles.
Vrai P.S.: le concept de disponibilité d'une frame de variables lors du scan de la pile (avant de dépilage) lors de la remontée d'une exception, c'est dans quelle partie de la norme ?
Quand j'ai une exception, je la gère ou je dump le bidule, je me base pas sur d'éventuelles fonctionnalités "fantômes" qui se basent sur des machins non standard.
P.P.S: Des vrais bugs, comme la mauvaise gestion des fichiers sources avec le même nom dans le débogueur de VS, oui, ça existe, mais l'affichage de variables pendant le scan de la pile lors d'une exception, c'est le genre de machin que semble apprécier les Dev ludiques qui codent vraiment comme des cochons (ça n'a pas changé depuis le précédent millénaire précédent à en croire le "code" en exemple).
P.P.P.S.: Testé sur un VS2017 Community Edition tout pété (même plus capable de créer un projet console C++ par défaut), et le débogueur fonctionne parfaitement avec le dernier code fourni, avec les options DEBUG par défaut (et même la liste des variables locales fonctionne parfaitement, quelque soit l'une des 2 frames).
Faudrait qu'ils donnent un peu leurs settings, parce que s'ils collent des options d'optimisations agressives, faut qu'ils maîtrisent un peu mieux la bête avant de venir pleurer comme des mioches).
=> c'est bien de la pub à 2 balles.
- Edité par bacelar 21 août 2023 à 22:31:32
Je recherche un CDI/CDD/mission freelance comme Architecte Logiciel/ Expert Technique sur technologies Microsoft.
P.P.P.S.: Testé sur un VS2017 Community Edition tout pété (même plus capable de créer un projet console C++ par défaut), et le débogueur fonctionne parfaitement avec le dernier code fourni, avec les options DEBUG par défaut (et même la liste des variables locales fonctionne parfaitement, quelque soit l'une des 2 frames).
Faudrait qu'ils donnent un peu leurs settings, parce que s'ils collent des options d'optimisations agressives, faut qu'ils maîtrisent un peu mieux la bête avant de venir pleurer comme des mioches).
Non il y a bien un problème, mais c'est pas seulement quand il y a une exception, c'est dès qu'on met un breakpoint et qu'on a envie de remonter la call stack en cliquant sur un des appels dans la liste de la call stack, on se retrouve sur l'instruction suivante au lieu de la ligne sur laquelle il y a l'appel. Donc ça fait que si l'appel était la dernière instruction du bloc, on peut plus inspecter les variables qu'il y a dedans vu qu'on est sorti donc c'est nul.
Mais c'est pas le seul problème qu'il y a avec Visual Studio, si vous voulez vous pouvez voir cette vidéo très instructive qui montre plusieurs problèmes qu'on rencontre avec VS : https://www.youtube.com/watch?v=wCllU4YkxBk
bacelar a écrit:
=> c'est bien de la pub à 2 balles.
C'est pas de la pub, c'est au contraire pour se rendre compte des problèmes qu'il y a pour pouvoir trouver des meilleurs solutions que Visual Studio, pour pouvoir être plus efficace quand on programme
Pour l'instant, on me dit que c'est trivial de faire un code qui exhibe le problème, moi, même sur un vieux VS tout pété avec le code fourni, j'arrive pas à le reproduire.
Ce n'est pas à moi de trouver un cas qui l'exhibe, quand même.
C'est toujours de la pub sans fondement.
Des bugs dans VS, il y en a pas mal, j'en ai l'"invention officiel" de certains, mais là, c'est un dahu.
C'est quand même pas la mort de poster un projet minimal pour reproduire le problème et le poster sur Github ou Gitlab, quand même.
La vidéo qui sert à rien : on voit un gus pester sur VS (normal ;-) ), mais on a aucune info claire sur ce qu'il fait, ce qu'il lui pose problème ou sur ces settings (j'ai jamais eu une IHM de VS qui ressemble à la sienne, des outils tiers ?)
@JadeSalina, des faits, du code, des bugs reproductibles, on demande pas la Lune, Bordel !
Je recherche un CDI/CDD/mission freelance comme Architecte Logiciel/ Expert Technique sur technologies Microsoft.
Comme dit dans les commentaires sur twitter-X, est-il pertinent de changer d’outil (qui fait beaucoup de choses) pour un petit bug ? (En particulier si la majorité des gens n’ont jamais rencontré ce bug en pratique).
Ca peut etre interessant de tester un nouvel outil comme remedyBG, mais perso l’UI ne me donne pas envie. Et je n’ai pas, pour le moment, de raison de penser qu’il fait un meilleur boulot (concrètement - pas avec des arguments osef) que VS ou d’autres.
En effet je ne peux pas consulter ma variable b dans ce cas. (testé avec Visual studio express 2019 sur ma machine perso, pas testé au boulot sous mon visual professionnel)
Cependant, j'utilise Visual depuis plus de 20 ans, et ça ne m'a jamais gêné. Surement que je ne suis pas tombé sur un cas qui m'a gêné de la sorte ?
Comme dit gbdivers, on ne va pas changer d'outil pour un petit bug.
Des millions de personnes bossent professionnellement sous Visual depuis des décennies, et ça fonctionne bien.
L'outil que tu proposes est très très austère je trouve.
Mais ouais, pour te donner crédit JadeSalinas, en effet ce serait bien si c'était corrigé oui...
C'est réellement un bug ? Dans le contexte de la fonction func(), b n'est effectivement pas défini. C'est pas juste un choix de comment fonctionne les watch ?
EDIT : bon, c'est étrange que a soit accessible et pas b. Donc ok, ça peut être effectivement considéré comme un bug. Le choix qui est fait, c'est que le contexte utilisé (la flèche verte sur ton screen) est la fonction suivante, c'est a dire après le contexte qui contient b. C'est un choix discutable, mais ca me semble pas etre un bug en soi.
C'est réellement un bug ? Dans le contexte de la fonction func(), b n'est effectivement pas défini. C'est pas juste un choix de comment fonctionne les watch ?
J'ai remonté la pile d'un cran, si on regarde la flèche verte dans la pile d'appel. Ce qui me permet d'avoir accès aux variables de la fonction appelante. Et je pourrais remonter autant que je veux si je venais de plus loin.
Mais par contre, ouais, c'est dommage, mais tu vois j'utilise ce debuggueur quasi au quotidien, et ça ne m'a jamais dérangé.
Mais ouais, après, aucun programme n'est sans bug, mais la c'est vraiment chercher des poux pour essayer de nous vendre un truc très très austère (et probablement beaucoup moins productif).
J'ai remonté la pile d'un cran, si on regarde la flèche verte dans la pile d'appel.
Justement, c'est bien indiqué (quand tu survoles la flèche verte avec la souris je crois) que c'est pas le même contexte. C'est pas le contexte qui correspond au moment du breakpoint, mais le moment après le retour de la fonction. Et à ce moment là, la variable b ne sera effectivement plus valide.
Je suis étonné qu'on ne puisse pas avoir exactement le même contexte au même moment (peut être que c'est possible autrement ou avec une option, mais je connais pas assez MSVC, c'est pas mon IDE principal).
Fvirtman a écrit:
et ça ne m'a jamais dérangé.
Après reflexion, je me suis demandé dans quelle condition ce choix pouvait poser problème ?
Dans ton code d'exemple, b n'est pas utilisé dans func() et n'est plus utilisé après func(). (Peut être même que le compilateur peut optimiser et supprimer b avant l'appel de func(), puisque cela ne change pas le comportement). A aucun moment, le comportement que l'on observe dans func() sera influencé (a priori) par la valeur de b et donc j'imagine qu'il n'y a aucun (ou quasi aucun) cas d'utilisation ou les devs regardent la valeur de b dans un tel contexte. Si on veut savoir la valeur de b, on mettra un breakpoint dans la fonction appelante, là où la valeur de b aura un impact sur l'execution du code.
Dans l'exemple du premier message, les variables de la fonction appelante sont utilisées dans la fonction appelées et donc c'est intéressant de voir leurs valeurs. Mais on les a, justement, dans les paramètres de la fonction. Si la personne avait regardé src et dst dans le contexte courant (et pas en regardant la fonction appelante dans la callstack), il aurait pu lire les valeurs de ces variables. Et j'imagine que c'est ce que font les devs par défaut et donc n'ont pas ce "bug".
Donc, globalement, ça ressemble a un faux cas d'utilisation. Soit les variables de la fonction appelante n'influencent pas la fonction appelée et les devs ne regardent pas ces variables, soit ces variables influencent le comportement et les devs y ont accès. Et donc personne n'a ce problème.
Oui, effectivement et je n'ai pas trouvé de plaintes sur le net à propos de ce bug. Et pourtant comme je disais on est des millions dans le monde à plancher sur Visual C++ pour notre boulot à plein temps.
Celui qui a trouvé ce soucis (mais c'est bien de l'avoir vu) n'était pas dans un cas qui le dérangeait, mais était dans une optique de vouloir dénigrer l'outil.
Ça fait longtemps qu'il n'est plus salarie comme dev. Ses propres projets de jeux sont pas sorti en plus de 10 ans. Il a sorti une BD (plus précisément la graphiste avec qui il bosse sur ses jeux. J'imagine qu'il touche une part). Il a aussi ce debugger (qui est payant il me semble).
Le plus gros de ses revenus doit venir des abonnements, qui permettent d’accéder a son code et d'autres choses (je crois).
C'est plus un influenceur qu'un dev au final. D’où sont cote polémique, ça fait vendre plus.
J'avais vu qu'il essayait de faire des jeux depuis des années sans avoir un truc de fonctionnel, tout en scandant à qui veut l'entendre qu'il programme mieux que tout le monde....
Mais je me disais qu'il avait peut être un boulot chronophage qui le ralentissait. Donc même pas du coup s'il ne bosse pas ?
Ah d'accord, le debuggueur concurrent, c'est le sien, donc il cherche des poux à celui de Visual pour vendre le sien, haha :)
Et je n’ai pas, pour le moment, de raison de penser qu’il fait un meilleur boulot (concrètement - pas avec des arguments osef) que VS ou d’autres.
Il est beaucoup plus rapide lors du debuggage et a plus de fonctionnalités (je vous renvoie à la vidéo de 20 minutes qui explique plein de fonctions géniales)
Fvirtman a écrit:
Cependant, j'utilise Visual depuis plus de 20 ans, et ça ne m'a jamais gêné.
Vous dites que ça ne vous gêne pas mais comment ça se fait ? Au contraire c'est vraiment infernal, si on rencontre la moindre exception et qu'on veut remonter pour justement savoir l'état des variables qui ont causé le plantage, et bien du coup on ne peut pas si jamais c'était la dernière instruction du bloc vu que le debugger va se placer juste après donc c'est vraiment très pénible.
gbdivers a écrit:
C'est réellement un bug ? Dans le contexte de la fonction func(), b n'est effectivement pas défini. C'est pas juste un choix de comment fonctionne les watch ?
EDIT : bon, c'est étrange que a soit accessible et pas b. Donc ok, ça peut être effectivement considéré comme un bug. Le choix qui est fait, c'est que le contexte utilisé (la flèche verte sur ton screen) est la fonction suivante, c'est a dire après le contexte qui contient b. C'est un choix discutable, mais ca me semble pas etre un bug en soi.
C'est peut-être pas un bug mais dans tous les cas c'est pas malin que ça se passe comme ça, vu que ça oblige à rajouter des instructions bidons à la fin des blocs pour être sûr qu'on pourra remonter la pile d'appel et voir les variables du bloc en cas d'exception, on le voit dans la vidéo de J Blow
Fvirtman a écrit:
c'est vraiment chercher des poux pour essayer de nous vendre un truc très très austère (et probablement beaucoup moins productif).
Comment ça moins productif ? Au contraire on perd pas de temps sur des trucs comme ça et on peut avancer pas à pas dans le code beaucoup plus vite alors que sur VS il faut attendre très longtemps entre chaque step on perd un temps fou. Et c'est pas austère c'est une interface faite avec imgui au contraire c'est très propre, il y a pas toutes ces fioritures des gros IDE qui encombrent le champ de vision.
gbdivers a écrit:
C'est plus un influenceur qu'un dev au final. D’où sont cote polémique, ça fait vendre plus.
Avant de commencer à faire des vidéos il avait déjà plus de 20 ans d'xp en programmation, les vidéos c'est juste un truc qu'il a commencé à faire comme ça sur son temps libre pour nous faire plaisir
Fvirtman a écrit:
J'avais vu qu'il essayait de faire des jeux depuis des années sans avoir un truc de fonctionnel
Il essaie pas de vendre des jeux, s'il sort pas de jeu c'est qu'il a pas envie ou pas besoin. En ce moment il fait une série de vidéos sur l'optimisation et il a prévu de faire un cours de programmation révolutionnaire sur Star Code Galaxy
- Edité par JadeSalina 3 septembre 2023 à 23:02:37
Il est beaucoup plus rapide lors du debuggage et a plus de fonctionnalités
Pour les fonctionnalités, on parlait bien sur de l'IDE complet Visual Studio et pas juste du debuggeur.
Et "plus rapide", si c'est pour afficher 2000 fois une variable par seconde, on s'en tape.
Mais oui, globalement, un outil qui fait plus de choses est plus lent. Typiquement, faire de l'indexation du code via clang, ce qui bouffe pas mal de ressources (en particulier sur les gros projets). Mais qui permet une aide contextuelle plus efficace.
Donc "plus rapide", sans préciser l'usage au jour le jour, ça veut pas dire grand chose. Perso, je trouve que mon IDE me fait gagner du temps, même si je vois bien que certaines fonctionnalités sont ralenties par la "grosseur" de l'IDE.
Et pour les arguments de la vidéo de 20 min, je vais pas détailler, mais c'est pas des arguments assez fort pour changer de debuggeur.
JadeSalina a écrit:
mais comment ça se fait ?
Lis les messages. On n'a jamais rencontré le problème décrit dans notre pratique de tous les jours, en plusieurs dizaines d'années.
JadeSalina a écrit:
c'est pas malin que ça se passe comme ça
Vu que personne n'a "jamais" ce problème en pratique, c'est un choix osef. (Je comprend pas ce choix, mais il est quand meme osef)
JadeSalina a écrit:
Comment ça moins productif ? (...) Et c'est pas austère
Que ça te plaise ou non, c'est un constat : beaucoup de devs ne vont pas être intéressé par cet outil, vont le trouver moins productif et vont le trouver austère.
Tu peux expliquer en quoi, TOI, dev non professionnel, tu trouves que c'est pas austère et que c'est productif, mais accepte que les autres devs (en particulier les pros, qui ont des besoins différents) n'aient pas forcément le même avis.
JadeSalina a écrit:
les vidéos c'est juste un truc qu'il a commencé à faire comme ça sur son temps libre pour nous faire plaisir
(...)
Il essaie pas de vendre des jeux
Sois cohérent avec ce que tu dis. S'il ne vend pas des jeux et s'il n'est plus salarié comme dev, c'est bien que son métier actuel, c'est de faire des vidéos. C'est son entrée d'argent. C'est pas un truc qu'il fait uniquement pour le plaisir, c'est son gagne pain. Ce que j'ai dit est donc correct, même si tu n'aime pas que je dise que c'est un influenceur et pas un dev.
Vous savez que, étant donné la structure interne des processeurs, il est tout à fait normal que le débuggeur ne puisse accéder qu'à l'instruction qui suit l'appel d'une fonction lorsque l'on remonte d'un cran dans la pile d'appels?
Allez, un petit rappel :
Le processeur dispose essentiellement de deux registres :
un qui contient l'instruction qu'il doit effectuer et un qui contient l'adresse qui suit l'instruction qui doit être effectuée.
je ne sais plus exactement comment ils s'appellent( mes cours remontent à longtemps) on va dire que c'est "tocall" et "next".
Concrètement, ce que le processeur fait, c'est :
charger dans "tocall" l'instruction qu'il trouve à l'adresse mémoire indiquée par next
incrementer "next"
exécuter l'instruction qui se trouve dans "tocall"
recommencer en (1)
A noter que des instructions comme JUMP, JE (Jump Equal) , JNE (Jump Not Equal) et autres vont ... modifier l'adresse qui se trouve dans next en fonction du résultat obtenu lors de la comparaison qui les a précédées.
Maintenant, réfléchissons un peu à ce qui se passe lors de l'appel d'une fonction:
on charge l'instruction CALL dans "tocall"
on incrémente "next"
on exécute CALL qui sauvegarde sur la pile l'adresse qui se trouve ... dans next
on recommence en un avec l'adresse à laquelle se trouve la première instruction de la fonction
Ce qui permettra, à la fin de la fonction appelée (à l'instruction RET), de récupérer l'adresse de l'instruction qui suit le CALL et donc de reprendre l'exécution de la fonction appelante.
Enfin, réfléchissons un peu aux informations auquelles le debuggueur a accès en gros, c'est simple: il a accès au différents registres, à la mémoire en générale et ... à la pile d'appels.
Donc, si on lui demande de trouve une instruction venant de la fonction appelante dans la file d'appel, la seule information qu'il sait avoir été sauvée dans la pile d'appels à ce sujet est l'adresse qui se trouvait dans "next"
Et, bien sur, il ne peut pas décider "arbitrairement" de décrémenter cette adresse en espérant atteindre pour la simple et bonne raison qu'il n'a aucune garantie d'y trouver effectivement le call.
Il est donc parfaitement logique qu'il pointe sur ... l'instruction qui va être effectuée dans le code et qu'il revienne ben ... sur l'instruction qui devra être effectuée après l'appel d'une fonction
- Edité par koala01 6 septembre 2023 à 8:19:38
Ce qui se conçoit bien s'énonce clairement. Et les mots pour le dire viennent aisément.Mon nouveau livre : Coder efficacement - Bonnes pratiques et erreurs à éviter (en C++)Avant de faire ce que tu ne pourras défaire, penses à tout ce que tu ne pourras plus faire une fois que tu l'auras fait
Cependant, j'utilise Visual depuis plus de 20 ans, et ça ne m'a jamais gêné.
Vous dites que ça ne vous gêne pas mais comment ça se fait ? Au contraire c'est vraiment infernal, si on rencontre la moindre exception et qu'on veut remonter pour justement savoir l'état des variables qui ont causé le plantage, et bien du coup on ne peut pas si jamais c'était la dernière instruction du bloc vu que le debugger va se placer juste après donc c'est vraiment très pénible.
Je comprends, comme je te disais, je trouve en effet dommage qu'il y ait ce bug. Mais je l'ai découvert que suite à ton message !
Et pourtant j'utilise le debuggueur de Visual tous les jours et ça ne m'a pas sauté aux yeux !
Alors tu peux penser que je code mal je ne sais pas, mais ça ne m'a jamais gêné, mais ce serait bien que Visual corrige cela malgré tout !
mais ce serait bien que Visual corrige cela malgré tout !
Si personne n'a reporté le problème depuis 20 ans, est-ce réellement nécessaire de corriger ? Je pense que Jade n'a pas non plus rencontré ce problème et je ne serais pas surpris que Casey et Jonathan Blow non plus.
il est tout à fait normal que le débuggeur ne puisse accéder qu'à l'instruction qui suit l'appel d'une fonction lorsque l'on remonte d'un cran dans la pile d'appels?
Sauf que c'est un comportement spécifique à MSVC. Avec LLDB par exemple, j'ai accès aux variables en remontant la callstack. Tes explications sont trop simplistes.
Comme dit bacelar, le debugger a accès a plus d'informations, par exemple les DWARF. Une vidéo sur le sujet https://youtu.be/0DDrseUomfU
× Après avoir cliqué sur "Répondre" vous serez invité à vous connecter pour que votre message soit publié.
× Attention, ce sujet est très ancien. Le déterrer n'est pas forcément approprié. Nous te conseillons de créer un nouveau sujet pour poser ta question.
Si vous ne trouvez plus rien, cherchez autre chose.
Le Tout est souvent plus grand que la somme de ses parties.
Le Tout est souvent plus grand que la somme de ses parties.
Discord NaN. Mon site.
Recueil de code C et C++ http://fvirtman.free.fr/recueil/index.html
Discord NaN. Mon site.
Recueil de code C et C++ http://fvirtman.free.fr/recueil/index.html
Discord NaN. Mon site.
Recueil de code C et C++ http://fvirtman.free.fr/recueil/index.html
Discord NaN. Mon site.
Recueil de code C et C++ http://fvirtman.free.fr/recueil/index.html
Discord NaN. Mon site.
Discord NaN. Mon site.
Recueil de code C et C++ http://fvirtman.free.fr/recueil/index.html
Discord NaN. Mon site.