Sauriez-vous m'expliquer l'utilisation du double pointeur (**)

Bonjour tout le monde,

Sauriez-vous svp m'expliquer à quoi sert exactement le double * (**) ?

Voici un exemple concret de mon cours :

Code:

---

1 2 3 4 5 6 7

void* Nouveau = realloc(m_Tableau,(m_Nombre+1)*sizeof(CReleve*)); if (Nouveau == NULL) return false; m_Tableau = (CReleve**)Nouveau; m_Tableau[m_Nombre] = new CReleve; if (m_Tableau[m_Nombre] == NULL) return false; m_Nombre++; return true;

---

Je vous en remercie d'avance.

Bon Dimanche.

beegees

Quand tu as :

Code:

---

m_Tableau = (CReleve**)Nouveau;

---

Nouveau est un pointeur sur une zone mémoire, de type indéterminé. C'est à dire qu'il pointe sur le premier élément de cette zone.

Là, tu vas forcer par l'intermédiaire d'un cast Nouveau à être considéré comme un pointeur vers un pointeur de CReleve. Dans ce pointeur de pointeurs, les deux pointeurs n'ont pas le même rôle. Le pointeur bleu est un pointeur classique, le pointeur rouge va par la suite être utilisé avec de l'arithmétique de pointeur (par exemple quand tu écris m_Tableau[m_Nombre]) afin de naviguer dans la mémoire allouée comme s'il s'agissait d'un tableau.

Dans un certain sens, ce code gère donc l'agrandissement d'un tableau de pointeurs.

Dans un certain sens seulement, car ce code a plein de problèmes :
- L'utilisation de realloc n'est possible qui si ce qu'on ré alloue répond à certains critères précis (un peu longs à citer ici. Il faut que ce soit un POD, en gros, dès qu'il s'agit d'une vrai classe, et non plus d'une donnée existant en C, ça n'est plus valide). Dans notre cas, on ré alloue des CReleve*, et les pointeurs répondent à ces critères, donc ça marche. Mais dans le cas général (ou si l'on remplace les pointeurs par des pointeurs intelligents), realloc peut poser des problèmes.
- tester qu'un new ne retourne pas NULL est idiot, car new ne peut pas retourner NULL (il lance une exception en cas de manque de mémoire).
- Il semble que ce code gère l'extension d'un tableau existant. Par contre la complexité de l'algorithme utilisé va dépendre fortement de l'état de la mémoire (car il se base sur realloc), ce qui fait que je n'ai aucune idée de la complexité de l'ajout de N éléments avec cet algorithme. Je préfère pour ma part un algorithme dont je maîtrise la complexité.

En C++, on gérera en général un tableau de pointeurs redimensionnable avec un simple std::vector<CReleve*> (ou des structures plus évoluées, suivant ce qu'on veut faire de ces pointeurs par la suite). On n'a plus alors à se préoccuper des aspects bas niveau de gestion de mémoire.

Par curiosité, ce cours vient-il d'un livre ? Si oui lequel ?

Bonjour,

Merci beaucoup pour ton explication.

Je vais relire attentivement ta réponse mais je réponds d'abord à ta quesiton :

Code:

---

Par curiosité, ce cours vient-il d'un livre ? Si oui lequel ?

---

Non, s'est notre prof qui nous apprend le C++ de cette façon.

Je pense qu'il essaie de nous montrer la différence entre C et C++ (on vient juste de terminer le cours de C).

Merci encore.

beegees

Si c'est le même prof de C++ qui vous apprenait le C sur un compilo C++ et avec du passage par référence C++, tu peux déjà ignorer tout ce qu'il vous dira.

Note sur le coup du new retournant NULL: C'était une pratique datant d'avant le standard, pratique suivie notamment par Visual C++ 6.0. Désormais obsolète, new lançant une exception de type std::bad_alloc en cas d'échec.

Salut,

Citation:

---

- Le code est incorrect, et peut provoquer des plantages, pour peu que la classe CReleve ne réponde pas à certains critères précis (un peu longs à citer ici. Il faut que ce soit un POD, en gros, dès qu'il s'agit d'une vrai classe, et non plus d'une struct du C, ça n'est plus valide).

---

@JolyLoic:
Pourrais-tu expliciter ce point ? Pourquoi faut-il que ce soit un POD ?

D'avance merci.

Tout simplement parce que realloc copie la mémoire de manière bourine, à la memcpy, s'il n'a pas simplement de la mémoire disponible au bout de la zone existante, et que ce genre d'opération n'est pas spécifié pour des objets qui ne sont pas des PODs.

Désolé, je ne comprends toujours pas. Dans le code de Beegees, realloc est utilisée pour redimensionner un tableau de pointeurs donc je ne vois pas le problème que pourrait poser l'utilisation d'une classe non-POD.

Oups, tu as raison, je me suis laissé emporté par ma crainte du réalloc. Je corrige mon premier message.