Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

C++ Discussion :

Meilleur debuggeur windows


Sujet :

C++

  1. #1
    Rédacteur

    Meilleur debuggeur windows
    Bonjour,
    Histoire d'avoir d'autres avis, qu'elle est, pour vous, le meilleur debuggeur sous windows? J'en connait que 2 :
    * gdb
    * celui de visual (cdb il me semble, ou alors ça fait trois )

    Pour moi c'est celui de visual qui le meilleur sous windows car :
    * pas à pas, break points,.. visual est beaucoup plus rapide que gdb.
    * visualisation de variable, visual est beaucoup plus puissante que gdb.

    Qu'en pensez vous? y as t'il des chose que gdb peut faire et non visual? (et inversement)


    pour votre expérience.

  2. #2
    Rédacteur

    Je suis plutot utilisateur du debugger Visual j'ai eu l'occasion d'utiliser gdb sous windows et j'ai trouvé que c'etiat vraiment pas super (Tres lent, on pouvait pas voir le contenu de tout les les types d'objets...). En définitive avec ma petite experience je dirais que le debugger visual sous windows a quand meme une tres tres grosse avance sur gdb...

    PS: Yan tu devrais peut etre faire une sondage dans ce poste sur le sujet.
    Vous voulez participer aux Tutoriels, FAQ ou Traductions et faire partie de l'équipe Qt de Developpez.
    N'hésitez pas à me contacter par MP.

  3. #3
    Membre habitué
    Visual aussi puis avec tout les addons qu'on peut trouver, il y en a un très bon qui donne les memory leaks, le fichier, la ligne et meme le nom de la variable qui leak...

  4. #4
    Membre confirmé
    Bonjour,
    J'ai utilisé GDB avec QtCreator, c'est très lent comme debugger, je pense que le debugger GDB est plus adapté à linux, et pour la programmation sans IDE avec kate ou vi.
    Cordialement.

    ps : meme gdb ne debuggera pas Buggen
    If you type Google into Google, you Can break the internet" - The IT Crowd

  5. #5
    Expert éminent
    Bonjour,

    pour windows, je ne connais rien de mieux que le debugger de visual. Et en fait, je ne pense pas qu'il soit possible de faire mieux: windows reste bien fermé et seuls les developpers de chez microsoft ont accès aux connaissances nécessaires.
    Tester c'est douter, corriger c'est abdiquer.

  6. #6
    Rédacteur

    Citation Envoyé par r0d Voir le message
    Bonjour,

    pour windows, je ne connais rien de mieux que le debugger de visual. Et en fait, je ne pense pas qu'il soit possible de faire mieux: windows reste bien fermé et seuls les developpers de chez microsoft ont accès aux connaissances nécessaires.
    Je sais pas. Qt ont ajouté un support dans QtCreator qui permet d'afficher correctement le contenu de certaine de leur classe, comme QString. Et ceux pour gdb et cdb.

  7. #7
    Inactif  
    En multiprocess, ou lorsque l'on a besoin de breakpoints hardware, il y a aussi WinDbg.... Dans de rares cas, il dépasse en puissance celui de Visual.
    Mac LAK.
    ___________________________________________________
    Ne prenez pas la vie trop au sérieux, de toutes façons, vous n'en sortirez pas vivant.

    Sources et composants Delphi sur mon site, L'antre du Lak.
    Pas de question technique par MP : posez-la dans un nouveau sujet, sur le forum adéquat.

    Rejoignez-nous sur : ► Serveur de fichiers [NAS] ► Le Tableau de bord projets ► Le groupe de travail ICMO

  8. #8
    Rédacteur

    Citation Envoyé par Mac LAK Voir le message
    En multiprocess, ou lorsque l'on a besoin de breakpoints hardware, il y a aussi WinDbg.... Dans de rares cas, il dépasse en puissance celui de Visual.
    ha ok. donc cdb n'est pas celui de visual. Le lien que tu donne, c'est celui que support QtCreator

  9. #9
    Inactif  
    Citation Envoyé par yan Voir le message
    ha ok. donc cdb n'est pas celui de visual. Le lien que tu donne, c'est celui que support QtCreator
    WinDbg est le debugger Microsoft pour (notamment) le mode kernel et le debug d'une machine distante.

    Il est moins convivial que celui intégré à Visual, mais permet des choses supplémentaires... Notamment les hardware breakpoints et quelques fioritures de plus sur la gestion des processus.
    Mac LAK.
    ___________________________________________________
    Ne prenez pas la vie trop au sérieux, de toutes façons, vous n'en sortirez pas vivant.

    Sources et composants Delphi sur mon site, L'antre du Lak.
    Pas de question technique par MP : posez-la dans un nouveau sujet, sur le forum adéquat.

    Rejoignez-nous sur : ► Serveur de fichiers [NAS] ► Le Tableau de bord projets ► Le groupe de travail ICMO

  10. #10
    Expert éminent
    Heu... je croyais que les deux était liés quand même...
    D'ailleurs sous visual je debug une machine distante sans problême !

    Mais bon... celui de visual est bien pratique... La possibilité de 'customiser' par code son affichage de variables très facile à utiliser (pour afficher l'état des objets par exemple). Le hook immédiat en cas d'exception non gérées...
    N'oubliez pas de cliquer sur mais aussi sur si un commentaire vous a été utile !
    Et surtout

  11. #11
    Inactif  
    Citation Envoyé par nicroman Voir le message
    D'ailleurs sous visual je debug une machine distante sans problême !
    Oui, une application "normale", en mode utilisateur... Pas quelque chose en mode kernel, pas même en local sur ta machine. De plus, le debugger intégré de Visual (très bien fait, hein, je ne le critique pas !) panique parfois lors du debug simultané de plusieurs processus, alors que WinDbg s'en sort (un peu) mieux.

    WinDbg est plus "puissant", mais également un peu plus barbare à utiliser... A réserver quand celui intégré à Visual montre ses limites.
    Mac LAK.
    ___________________________________________________
    Ne prenez pas la vie trop au sérieux, de toutes façons, vous n'en sortirez pas vivant.

    Sources et composants Delphi sur mon site, L'antre du Lak.
    Pas de question technique par MP : posez-la dans un nouveau sujet, sur le forum adéquat.

    Rejoignez-nous sur : ► Serveur de fichiers [NAS] ► Le Tableau de bord projets ► Le groupe de travail ICMO

  12. #12
    Rédacteur

    es ce quelqu'un connait la raison de cette différence de puissance entre gdb et les debugger windows?
    J'avais entendu un truc comme quoi ca viendrais de la façon dont sont généré les binaires par gcc

  13. #13
    Inactif  
    Citation Envoyé par yan Voir le message
    es ce quelqu'un connait la raison de cette différence de puissance entre gdb et les debugger windows?
    Sûrement le fait qu'il n'est pas vraiment conçu pour Windows... Les systèmes Unix sont axés processus, les systèmes Windows sont axés threads. Mine de rien, ça change pas mal de choses, j'ai déjà vu des portages d'appli Windows "brutaux" sous Linux devenir de vraies bouses à cause des threads, et réciproquement, des applis Linux à base de processus (et de fork(), donc) se comporter minablement sous Windows.

    Citation Envoyé par yan Voir le message
    J'avais entendu un truc comme quoi ca viendrais de la façon dont sont généré les binaires par gcc
    Sous Windows, ça revient au même : c'est un exécutable au format PE, c'est le système d'exploitation qui décide du format à utiliser, pas le compilateur.
    Mac LAK.
    ___________________________________________________
    Ne prenez pas la vie trop au sérieux, de toutes façons, vous n'en sortirez pas vivant.

    Sources et composants Delphi sur mon site, L'antre du Lak.
    Pas de question technique par MP : posez-la dans un nouveau sujet, sur le forum adéquat.

    Rejoignez-nous sur : ► Serveur de fichiers [NAS] ► Le Tableau de bord projets ► Le groupe de travail ICMO

  14. #14
    Membre expert
    tout dépend du compilateur et de ton environnement de dev que tu vas utiliser je pense.

    effectivement si tu fait tes dev sous visual studio celui de windows sera très probablement mieux.

    maintenant si tu développe avec mingw (gcc) par exemple il vaudrait mieux utiliser gdb.

    concernant gdb il existe s'intègre bien dans tout un paquet d'ide et d'éditeurs open source.
    bazar: http://www.improetcompagnie.com/publ...ctacles-6.html

    BÉPO la disposition de clavier francophone, ergonomique et libre: http://bepo.fr/wiki/Accueil

    Emacs Wiki: http://www.emacswiki.org/

    En attente de ce que produira: http://www.pushmid.com

  15. #15
    Membre émérite
    des portages d'appli Windows "brutaux" sous Linux devenir de vraies bouses à cause des threads, et réciproquement, des applis Linux à base de processus (et de fork(), donc) se comporter minablement sous Windows
    C'est vieux, ça, non ? Depuis la glibc 2.6 et nptl, linux est très efficace sur la création de threads.

    Sinon, pour windows, windbg est le must, mais effectivement, très complexe à prendre en oeuvre (et aussi, un peu buggé parfois).

    Par contre, il me semble que gcc et visual génèrent les symboles différemment, autrement dit, si tu compiles avec gcc, tu es contraint à gdb, et avec visual, contraint à visual ou windbg.

  16. #16
    Inactif  
    Citation Envoyé par white_tentacle Voir le message
    C'est vieux, ça, non ? Depuis la glibc 2.6 et nptl, linux est très efficace sur la création de threads.
    Moins mauvais plutôt, je dirais... Je trouve toujours, pour l'instant, que le scheduling sous Windows est bien plus efficace que celui sous Linux au niveau threads, notamment en ce qui concerne les changements de contextes sur les changements d'état des objets de synchro.

    Citation Envoyé par white_tentacle Voir le message
    Sinon, pour windows, windbg est le must, mais effectivement, très complexe à prendre en oeuvre (et aussi, un peu buggé parfois).
    Il est en effet "brut de décoffrage".

    Citation Envoyé par white_tentacle Voir le message
    Par contre, il me semble que gcc et visual génèrent les symboles différemment, autrement dit, si tu compiles avec gcc, tu es contraint à gdb, et avec visual, contraint à visual ou windbg.
    Je crois qu'il existe une option pour permettre d'utiliser WinDbg quand même, mais c'est sous réserve... J'ai vu passer sur je ne sais plus quel compilateur Windows la possibilité de créer les symboles suivant plusieurs formats.
    Mac LAK.
    ___________________________________________________
    Ne prenez pas la vie trop au sérieux, de toutes façons, vous n'en sortirez pas vivant.

    Sources et composants Delphi sur mon site, L'antre du Lak.
    Pas de question technique par MP : posez-la dans un nouveau sujet, sur le forum adéquat.

    Rejoignez-nous sur : ► Serveur de fichiers [NAS] ► Le Tableau de bord projets ► Le groupe de travail ICMO

###raw>template_hook.ano_emploi###