none
usage du debug? RRS feed

  • Question

  • bonjour;

    J'aimerai mettre un point d’arrêt sur l’accès à une variable?

    J'ai trouvé dans le debug sur le choix nouveau point d’arrêt un sous menu mais il est grisé.

    qui peut m'orienter sur la procédure à mettre en place?


    Jean Noël Martin


    jeudi 23 janvier 2014 04:29

Réponses

  • Ne comulez pas les difficultés.

    Ne faites la bascule Natif=>Managé qu'une fois que le parser fonctionne correctement en Natif.

    Remplacer des "new/delete" par des "malloc/free" n'est pas une manière très orthodoxe de "corriger" un code qui semble avoir été utilisé dans de nombreux projets avec succès.

    Généralement, ce type de problème est plus dans le domaine du paramétrage du projet et de modification de chaine de compilation.

    Le find-and-replace shotgun dans les sources, ça fait toujours des victimes collatérales.


    Paul Bacelar, Ex - MVP VC++

    • Marqué comme réponse JeanNoel53 mercredi 29 janvier 2014 15:25
    mercredi 29 janvier 2014 11:02
    Modérateur

Toutes les réponses

  • Quel type de projet ? Quel sous-menu ? svp ?

    Paul Bacelar, Ex - MVP VC++

    jeudi 23 janvier 2014 09:29
    Modérateur
  • dans le choix de menu le débogue est en 6° position. Et quand on le sélectionne il apparait le choix de nouveaux points d’arrêt:Mais quand on clic dessus le choix de mise de point d’arrêt sur une variable est grisé;

    Apparemment il y a une autre solution: sur un point d’arrêt on met le nom de la variable et on spécifie a changé. Je vérifie et je reviens: En fait ce point d’arrêt fonctionne bien à l'initialisation, mais pas bien quand la donnée est pervertie.


    Jean Noël Martin


    jeudi 23 janvier 2014 12:23
  • C'est une question ou une charade ???

    Les positions dans les menus sont fonction de l'ensemble des outils installés, et un menu est hiérarchique, donc avec un chiffre, on va pas loin. Il existe un truc super dans les contrôles de menu, la propriété Name. :-{

    Alors je propose, comme réponse à cette charade :

    http://msdn.microsoft.com/en-us/library/350dyxd0(v=vs.90).aspx

    C'est marqué C++ Nalive ONLY.

    Je suppute que vous avez salopé la mémoire (je suppose la native, car sinon, vous êtes balaise).

    Le plus simple dans ce cas, c'est d'activer la vérification systématique de la mémoire au début du programme :

    http://msdn.microsoft.com/en-us/library/e73x0s4b.aspx


    Paul Bacelar, Ex - MVP VC++

    jeudi 23 janvier 2014 16:42
    Modérateur
  • Bonjour

    Un petit retour Jean Noël ?

    Merci!


    Aurel BERA, MSFT
    MSDN Community Support. LE CONTENU EST FOURNI "TEL QUEL" SANS GARANTIE D'AUCUNE SORTE, EXPLICITE OU IMPLICITE.
    S'il vous plaît n'oubliez pas de "Marquer comme réponse" les réponses qui ont résolu votre problème. C'est une voie commune pour reconnaître ceux qui vous ont aidé, et rend plus facile pour les autres visiteurs de trouver plus tard la résolution.

    lundi 27 janvier 2014 10:20
  • Je suis dans un état intermédiaire entre la résolution des allocations et le fait que le parser marche bien.

    Je vous tiendrais au courant


    Jean Noël Martin

    lundi 27 janvier 2014 13:54
  • Est-ce que le problème était bien un accès à la RAM "sauvage" ?

    Si oui, est-ce que la vérification systématique de la mémoire à permit de déterminer le code incriminé.

    Sinon, comment avez-vous trouvé le code problématique ?

    Si cela n'a rien à voir avec un accès sauvage à la RAM, pourquoi ? Comment avez-vous résolu ou contourner le problème ?


    Paul Bacelar, Ex - MVP VC++

    lundi 27 janvier 2014 16:52
    Modérateur
  • il y avait des problèmes d'allocation de mémoire sur des new. J'ai tourné ce problème en passant par des malloc. En en discutant avec ma femme, nous avons entrepris de passer le parser de brill en mode managé. Ce qui aujourd'hui est à moitié fait.

    Jean Noël Martin

    mardi 28 janvier 2014 17:10
  • Ne comulez pas les difficultés.

    Ne faites la bascule Natif=>Managé qu'une fois que le parser fonctionne correctement en Natif.

    Remplacer des "new/delete" par des "malloc/free" n'est pas une manière très orthodoxe de "corriger" un code qui semble avoir été utilisé dans de nombreux projets avec succès.

    Généralement, ce type de problème est plus dans le domaine du paramétrage du projet et de modification de chaine de compilation.

    Le find-and-replace shotgun dans les sources, ça fait toujours des victimes collatérales.


    Paul Bacelar, Ex - MVP VC++

    • Marqué comme réponse JeanNoel53 mercredi 29 janvier 2014 15:25
    mercredi 29 janvier 2014 11:02
    Modérateur