Discussion :

[djuju]

Bonjour,

Je développe une librairie qui historiquement était procédurale.
Depuis quelques temps déjà, notre volonté est de faire des refactorings pour la rendre OO et surtout plus clean.

Hors, avec l'OO, nous rencontrons des problèmes pour évaluer les valeurs de retour des fonctions en debug.

Jusque là, lorsque nous voulions voir la valeur d'une variable imbriquée dans une structure de données il suffisait de breaker dessus et de survoler la variable dans le code.
Par exemple:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

containerAInst.arrayPtrB[i].valueC // <= En survolant n'importe quelle variable de cette chaine, je pouvais voir sa valeur.

Maintenant, mon code ressemble plus à ça :
> containerA.h <

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
 
#include "containerB.h"
 
class containerA {
private:
  containerB *arrayPtrB; // Un tableau dynamique
 
public:
  containerA() {/*init arrayPtrB*/}
  ~containerA() {/*delete arrayPtrB*/}
 
  containerB& operator[](const unsigned int pIndex);
  containerB& operator[](const unsigned int pIndex) const;
  containerB& mGetContainerBAt(const unsigned int pIndex);
  containerB& mGetContainerBAt(const unsigned int pIndex) const;
}

> containerA.cpp <

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
 
#include "containerA.h"
 
containerB& containerA::mGetContainerBAt(const unsigned int pIndex)
{
  return arrayPtrB[pIndex];
}
 
containerB& containerA::operator[](const unsigned int pIndex)
{
  return mGetContainerBAt(pIndex);
}
 
containerB& containerA::mGetContainerBAt(const unsigned int pIndex) const
{
  return const_cast<containerA*>(this)->mGetContainerBAt(pIndex);
}
 
containerB& containerA::operator[](const unsigned int pIndex) const
{
  return mGetContainerBAt(pIndex);
}

> containerB.hpp <

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
class containerB {
  int valueC; // Oui, c'est public. Il en reste encore quelques uns dans mon code, mais c'est surtout pour l'exemple.
  int valueB;
  bool isC;
}

Mon appel à travers des structures devient donc:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

containerAInst[i].valueC

Ou:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

containerAInst.mGetContainerBAt(i).valueC

Le code ci-dessus est très simplifié : pas de polymorphisme, pas des fonctions virtuelles, juste une surcharge de la fonction mGetContainerBAt et l'opérateur [].
Pourtant, que je demande à VC d'évaluer l'un ou l'autre de des deux appel ci-dessus, j'ai toujours une erreur.

Après quelques lecture sur le web et quelques tests, je me suis aperçu que le problème venait de la surcharge des fonctions. Si je retire les deux fonctions const de mon code, ça marche.
Mais bon, d'une part je suis obligé de faire des const_cast un peu partout ou ne plus utiliser d'instance const. D'autre part, c'est quand même le but du polymorphisme de pouvoir surcharger des fonctions, les redéfinir virtuellement etc...

Pour l'instant, je n'ai que des workarrouds non satisfaisants:
1 - Ajouter dans la watch window "containerAInst.arrayPtrB[i].valueC". <= Trop fastidieux à écrire à chaque fois qu'on a besoin d'une valeur... Et en plus ca oblige à connaitre l'implémentation de la fonction appelée.
2 - Utiliser les autos qui affichent les valeurs de retour des derniers appels. <= Satisfaisant lorsque le type de retour est primitif, mais lorsque c'est une instance d'un objet, on ne peut pas voir toutes les valeurs, ni naviguer dedans.

J'imagine qu'il y a une solution à mon problème, pas mal de dev. travaillent sous VC++ au quotidien, mais je n'arrive pas à la trouver.
Pouvez-vous m'aider SVP ?

S'il n'y a pas de solution sous VC++, est-ce que le compilateur d'Intel ou un autre ferait mieux ?

NOTE: Mon code est composé d'une interface graphique managée et d'une lib statique native (pas de MFC). Je développais sous VS2010 compilé en vc9 (le problème était identique), mais je viens de migrer mon code en vc11 sous VS2012 depuis quelques jours.

d'avance pour votre aide !!
Ju

[moldavi]

Bonjour.

Je rencontre parfois ce problème aussi.

J'utilise trois cas de figure :

- J'assigne la valeur que je souhaite débugger à une variable temporaire.
- Je log la valeur dans un fichier.
- J'utilise Debug:: Print.

Lorsque les tests sont terminés, je supprime les variables inutiles.

[djuju]

Merci de ta réponse Moldavi,

Pour l'instant, j'utilise aussi des variables temporaires. Mais c'est un plutôt lourd comme procédure. Ca oblige à arrêter ma session de debug, modifier le code et refaire mon test.
Si c'est la seule solution, je pense que je vais remettre en place le "Edit and continue" que j'avais abandonné à cause des comportements indéterminés qu'il générait parfois.

Sais-tu si c'est une limite de C++ qui a un modèle mémoire beaucoup plus simple que java par exemple, ou si c'est une limite du compilateur de microsoft et/ou de Visual Studio ?
Autrement dit, si je passe sur le compilateur d'Intel est-ce que ça marchera mieux ?

Merci

[djuju]

J’oubliais,

L'écriture dans un fichier est difficile car la majorité de mes threads sont "time critical".
Le Debug:: print est bien pour les types simple, mais pour explorer un objet, c'est pas top.

Encore merci

[moldavi]

Re.

Pour les autres compilateurs, je ne peux pas te répondre, je ne connais que VS. Il me semble que je n'ai ce problème qu'avec VS2012 RC.

Pour visionner les objets dans la console de débugage, je crée une fonction genre ToString() dans la classe de mon objet.

Pour les tests "time critical", j'alloue de la mémoire, je log dans cette mémoire et à la fin du test, je log dans le fichier.

[djuju]

Merci de ton aide !!