C++ et éléments finis Note de cours de DEA (version provisoire)

10 CHAPITRE 1. QUELQUES ÉLÉMENTS DE SYNTAXE
Il est fondamental de vérifier les bornes de tableaux, ainsi que les autres bornes connues. Aujourd’hui je
viens de trouver une erreur stupide, un déplacement de tableau dû à l’échange de 2 indices dans un tableau
qui ralentissait très sensiblement mon logiciel (je n’avais respecté cette régle).
Exemple d’une petite classe qui modelise un tableau d’entier
class Itab{ public:
int n ;
int *p ;
Itab(int nn)
{ n=nn) ;
p=new int[n] ;
assert(p) ;} // verification du pointeur
˜Itab()
{ assert(p) ; // verification du pointeur
delete p ;
p=0 ;} // pour eviter les doubles destruction
int & operator[](int i) { assert( i >=0 && i < n && p ) ; return p[i] ;}
private: // la regle 1 : pas de copie par defaut il y a un destructeur
Itab(const Itab &) ; // pas de constructeur par copie
void operator=(const Itab &) ; // pas d’affection par copie
}
Régle 4 N’utiliser le macro générateur que si vous ne pouver par faire autrement, ou pour ajouter du code
de verification ou test qui sera très utile lors de la mise au point.
Régle 5 Une fois toutes les erreurs de compilation et d’édition des liens corrigées, il faut éditer les liens en
ajoutant CheckPtr.o (le purify du pauvre) à la liste des objets à éditer les liens, afin de faire les vérifications
des allocations.
Corriger tous les erreurs de pointeurs bien sûr, et les erreurs assertions avec le débogueur.
1.3 Verificateur d’allocation
L’idée est très simple, il suffit de surcharger les opérateurs new et delete, de stocker en mémoire tous les
pointeurs alloués et de vérifier avant chaque déallacation s’il fut bien alloué (cf. AllocExtern::MyNewOperator(size t
) et AllocExternData.MyDeleteOperator(void *). Le tout est d’encapsuler dans une classe AllocExtern
pour qu’il n’y est pas de conflit de nom.
De plus, on utilise malloc et free du C, pour éviter des problèmes de récurrence infinie dans l’allocateur.
Pour chaque allocation, avant et après le tableau, deux petites zones mémoire de 8 octets sont utilisées pour
retrouver des débordement amont et aval.
Et le tout est initialisé et terminé sans modification du code source en utilisant la variable AllocExternData
globale qui est construite puis détruite. À la destruction la liste des pointeurs non détruits est écrite dans
un fichier, qui est relue à la construction, ce qui permet de deboguer les oublis de déallocation de pointeurs.
Remarque: Ce code marche bien si l’on ne fait pas trop d’allocations, destructions dans le programme,
car le nombre d’opérations pour vérifier la destruction d’un pointeur est en nombre de pointeurs alloués.
L’algorithme est donc proportionnel au carré du nombre de pointeurs alloués par le programme. Il est possible
d’améliorer l’algorithme en triant les pointeurs par adresse et en faisant une recherche dichotomique pour la
destruction.
Le source de ce vérificateur CheckPtr.cpp est disponible à l’adresse suivante FTP:CheckPtr.cpp. Pour l’utiliser,
il suffit de compiler et d’éditer les liens avec les autres parties du programme.
Il est aussi possible de retrouver les pointeurs non désalloués, en utilisant votre déboguer favorit ( par exemple
gdb ).
Dans CheckPtr.cpp, il y a une macro du préprocesseur DEBUGUNALLOC qu’il faut definir, et qui active l’appel de
la fonction debugunalloc() à la création de chaque pointeur non détruit. La liste des pointeurs non détruits
est stockée dans le fichier ListOfUnAllocPtr.bin, et ce fichier est génére par l’exécution de votre programme.
Donc pour déboguer votre programme, il suffit de faire:
1. Compilez CheckPtr.cpp.