• [^] # Re: smart pointer

    Posté par (site web personnel) . En réponse au journal Retour aux sources. Évalué à 2.

    pouvoir scripter un test, ajouter un breakpoint, modifier une variable avancer de 5 instructions, remodifier une variable, pour enfin être prêt à trouver un deuxième bug... et bien je suis content que gdb soit en ligne de commande, qu’on puisse lui passer des scripts, etc.

    Après, pour des softs avec IHM, un débogueur en IHM aussi peut suffire.

    Je ne suis pas sûr de bien comprendre, donc je vais éviter de m'énerver, parce que mon incompréhension vient peut-être simplement du fait que tu ne sais pas t'exprimer de manière construite, mais... si je lis ce que j'ai cité, j'en déduis que tu crois qu'on ne peut

    • ni ajouter de breakpoint à la volée
    • ni modifier de variable à la volée
    • ni faire du pas-à-pas

    avec un debugger "sale" (pour un langage "sale" genre Java dans un outil "sale" donc graphique) ?

    Dans quel monde tu vis ?

    Du coup je vais jouer au même jeu du "ma feature basique est inimaginable pour les autres" et poser des questions basées sur mon usage basique du debugger d'IntelliJ IDEA dans mon code Groovy.

    • Est-ce qu'avec ton gdb tu peux exprimer une condition pour activer ou non un breakpoint (genre "arrête-toi ici seulement si ceci et cela" en ayant accès à toute l'expressivité de groovy et même ta logique métier) ?
    • Est-ce que tu peux sélectionner une ligne de ton programme et cliquer/taper le raccourci clavier "j'ai pas mis de breakpoint mais relance le flot d'exécution jusqu'à cette ligne peu importe ce qu'il se passe" ?
    • Est-ce que tu peux abandonner le contexte courant ("drop frame" dans IntelliJ, désolé flemme de chercher mieux) en revenant au début de ta méthode et en remettant tout le contexte (variables, paramètres, etc.) dans l'état où il était au début histoire de revoir ce qu'il se passe ?