Triple pointeurs en C: est-ce une question de style?

À l'aide de triple+ pointeurs est nuire à la fois la lisibilité et la maintenabilité.

Supposons que vous avez un peu de déclaration de fonction ici:

void fun(int***);

Hmmm. L'argument est-il un en trois dimensions de tableau en escalier, ou un pointeur à deux dimensions du tableau en escalier, ou un pointeur de pointeur de tableau (comme dans la fonction alloue un tableau et attribue un pointeur de int dans une fonction)

Nous le comparons à:

void fun(IntMatrix*);

Sûrement, vous pouvez utiliser le triple de pointeurs sur int pour fonctionner sur les matrices. Mais ce n'est pas ce qu'ils sont. Le fait qu'ils sont mis en œuvre ici comme triple pointeurs est hors de propos à l'utilisateur.

Compliqué structures de données doivent être encapsulé. C'est l'une des idées de manifeste de la Programmation Orientée Objet. Même en C, vous pouvez appliquer ce principe dans une certaine mesure. Enveloppez la structure de données d'un struct (ou, très commun en C, en utilisant des "poignées", qui est, les pointeurs de type incomplète - cette doctrine sera expliqué plus tard dans la réponse).

Supposons que vous avez mis en œuvre les matrices telles que les tableaux irréguliers de double. Par rapport à contiguë 2D tableaux, ils sont pire lors de l'itération sur eux (comme ils n'appartiennent pas à un seul bloc de mémoire contiguë), mais de permettre l'accès à la notation de tableau et chaque ligne peut avoir différentes tailles.

Alors maintenant, le problème est que vous ne pouvez pas modifier les représentations maintenant, comme l'utilisation de pointeurs est câblé sur le code de l'utilisateur, et maintenant vous êtes coincé avec inférieures de mise en œuvre.

Ce ne serait pas même un problème si vous encapsulé dans une structure (struct).

typedef struct Matrix_
{
    double** data;
} Matrix;

double get_element(Matrix* m, int i, int j)
{
    return m->data[i][j];
}

obtient tout simplement changé de

typedef struct Matrix_
{
    int width;
    double data[]; //C99 flexible array member
} Matrix;

double get_element(Matrix* m, int i, int j)
{
    return m->data[i*m->width+j];
}

La poignée technique fonctionne comme ceci: dans le fichier d'en-tête, vous déclarez une incomplètes struct et toutes les fonctions que le travail sur le pointeur vers une struct:

//struct declaration with no body. 
struct Matrix_;
//optional: allow people to declare the matrix with Matrix* instead of struct Matrix*
typedef struct Matrix_ Matrix;

Matrix* create_matrix(int w, int h);
void destroy_matrix(Matrix* m);
double get_element(Matrix* m, int i, int j);
double set_element(Matrix* m, double value, int i, int j);

dans le fichier source, vous déclarez la réelle structure et de définir toutes les fonctions:

typedef struct Matrix_
{
    int width;
    double data[]; //C99 flexible array member
} Matrix;

double get_element(Matrix* m, int i, int j)
{
    return m->data[i*m->width+j];
}

/* definition of the rest of the functions */

Le reste du monde ne sait pas ce que fait le struct Matrix_ contenir et il ne sait pas la taille de celui-ci. Cela signifie que les utilisateurs ne peuvent pas déclarer les valeurs directement, mais seulement par l'utilisation d'un curseur pour Matrix et la create_matrix fonction. Cependant, le fait que l'utilisateur ne connaît pas la taille signifie que l'utilisateur ne dépend pas d'elle - ce qui signifie que l'on peut supprimer ou ajouter des membres à struct Matrix_ à volonté.

La plupart du temps, l'utilisation de 3 niveaux d'indirection est un symptôme par la mauvaise conception de décisions prises ailleurs dans le programme. Par conséquent, il est considéré comme une mauvaise pratique et il y a des blagues sur les "trois étoiles programmeurs" où, contrairement à la notation pour les restaurants, plus d'étoiles, de moins bonne qualité.

La nécessité pour les 3 niveaux d'indirection provient souvent de la confusion sur la façon d'attribuer correctement les multi-dimensions des tableaux dynamiquement. C'est souvent enseigné mal même dans les livres de programmation, en partie du fait de la faire correctement était un lourd fardeau avant le standard C99. Mon Q&Un post Correctement l'allocation de matrices multi-dimensionnelles aborde cette question et montre également comment plusieurs niveaux d'indirection va rendre le code plus difficile à lire et à maintenir.

Bien que ce post explique, il y a certaines situations où un type** peut avoir du sens. Une variable tableau de chaînes de caractères de longueur variable est un exemple. Et quand ce besoin de type** se pose, vous pourriez bientôt être tentés de l'utiliser type***, parce que vous avez besoin de retourner votre type** par le biais d'un paramètre de la fonction.

Le plus souvent, ce besoin s'en fait sentir dans une situation où vous êtes à la conception d'une sorte de complexe d'ADT. Par exemple, disons que nous sommes le codage d'une table de hachage, où chaque indice est un "enchaînés" lié liste, et chaque nœud dans la liste liée à un tableau. La bonne solution est donc de re-concevoir le programme à utiliser les structures au lieu de plusieurs niveaux d'indirection. La table de hachage, liste et tableau doit être de différents types, types autonomes sans la moindre conscience les uns des autres.

Ainsi, en utilisant une conception appropriée, nous permettra d'éviter les multiples étoiles automatiquement.

---

Mais comme avec toutes les règles de bonne programmation pratique, il y a toujours des exceptions. Il est parfaitement possible d'avoir une situation comme:

• Faut mettre en place un tableau de chaînes de caractères.
• Le nombre de cordes est variable et peut changer au moment de l'exécution.
• La longueur des chaînes est variable.

Vous peut mettre en œuvre le ci-dessus comme un guide pratique, mais il peut également exister des raisons valables pour garder les choses simples et il suffit d'utiliser un char* [n]. Vous avez alors deux options pour allouer dynamiquement:

char* (*arr_ptr)[n] = malloc( sizeof(char*[n]) );

ou

char** ptr_ptr = malloc( sizeof(char*[n]) );

L'ancien est plus formellement correct, mais aussi de la lourdeur. Car il doit être utilisé comme (*arr_ptr)[i] = "string";, tandis que l'alternative peut être utilisé comme ptr_ptr[i] = "string";.

Maintenant, supposons que nous avons à la place de malloc appel à l'intérieur d'une fonction et le type de retour est réservé à un code d'erreur, comme il est de coutume avec les C Api. Les deux solutions seront alors ressembler à ceci:

err_t alloc_arr_ptr (size_t n, char* (**arr)[n])
{
  *arr = malloc( sizeof(char*[n]) );

  return *arr == NULL ? ERR_ALLOC : OK;
}

ou

err_t alloc_ptr_ptr (size_t n, char*** arr)
{
  *arr = malloc( sizeof(char*[n]) );

  return *arr == NULL ? ERR_ALLOC : OK;
}

Il est assez difficile d'argumenter et de dire que le premier est plus lisible, et il est également livré avec la complexité de l'accès nécessaire par l'appelant. Les trois étoiles alternative est en fait plus élégant, dans ce cas très précis.

De sorte qu'il n'est pas bon pour rejeter les 3 niveaux d'indirection de façon dogmatique. Mais le choix de les utiliser doivent être bien informés, avec une prise de conscience qu'ils peuvent créer laid code et qu'il existe d'autres alternatives.

Après deux niveaux d'indirection, la compréhension devient difficile. Si d'ailleurs la raison pour laquelle vous êtes le passage de ces triple (ou plus) les pointeurs dans vos méthodes est de sorte qu'ils peuvent ré-allouer et re-régler certains ont indiqué à la mémoire, qui est loin de la notion de méthodes comme des "fonctions" que le juste retour des valeurs et n'affectent pas l'état. Cela nuit également à la compréhension et à la maintenabilité au delà d'un certain point.

Mais plus fondamentalement, vous avez touché à l'un des principaux stylistique des objections à la triple pointeur ici:

On peut clairement voir comment un triple pointeur (et au-delà, vraiment) serait nécessaire.

C'est la "et au-delà", c'est la question ici: une fois que vous obtenez à trois niveaux, où avez-vous l'arrêter? Sûrement, il possible d'avoir un aribitrary nombre de niveaux d'indirection. Mais c'est mieux d'avoir juste un coutumier limite dans un endroit où la lisibilité est bonne, mais la souplesse est adéquate. Deux est un bon nombre. "Les trois étoiles de la programmation", comme il est parfois appelé, est controversée au mieux; c'est brillant, ou un casse-tête pour ceux qui en ont besoin pour maintenir le code plus tard.