Discussion :

[takout]

Bonjour à tous,
J'aimerai savoir s'il est possible de créer des tableaux dynamiques contigus en C ?
généralement je fais ceci pour créer dynamiquement mes tableaux, mais malheureusement l'espace mémoire réservé n'est pas contigu.

Code :

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

1
2
3
4
 
 
  tab=malloc(nrow*sizeof(double*)); assert(tab!=NULL);
 for(i=0;i<nrow;++i){tab[i]=malloc(ncol*sizeof(double));assert(tab[i]!=NULL);}

[uknow]

Bonjour,

La norme C99 ne garantit pas que des appels successifs des fonctions d'allocation (malloc, calloc ou realloc) engendre un espace contigu.

7.20.3 Memory management functions :
The order and contiguity of storage allocated by successive calls to the calloc, malloc, and realloc functions is unspecified.

Après un peu de ruse pourrait faire l'affaire :

Code :

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

int ** pp = malloc( nRow * nCol * sizeof **pp );

[diogene]

Pour compléter ce que dit uknow, il faut allouer en une seule fois et placer les adresses correctement dans le tableau de pointeurs :

Code :

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

1
2
3
  tab=malloc(nrow*sizeof(double*)); assert(tab!=NULL);
  tab[0] = malloc(nrow*ncol*sizeof(double)); assert(tab[0]!=NULL);
  for(i=1;i<nrow;++i) tab[i] = tab[i-1]+ncol;

[Trademark]

Une autre solution est d'aplatir ton tableau :

Code :

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

1
2
3
4
double* tab=malloc(nrow * ncol *sizeof double);
for(int i=0; i < nrow; ++i)
  for(int j=0; j < ncol; ++j)
    tab[i*ncol + j] = 0.0;

Sinon il ne faut pas faire d'assert après un malloc, c'est illogique... Si un malloc foire, ça ne veut pas dire qu'il y a une erreur de programmation ou qu'on viole quoi que ce soit mais simplement qu'il n'y plus de mémoire... D'autant plus qu'en mode release, les assert sont désactivé, donc si malloc foire chez un client ça lui fera une belle segfault

[Neckara]

Bonjour,

La norme C99 ne garantit pas que des appels successifs des fonctions d'allocation (malloc, calloc ou realloc) engendre un espace contigu.



Après un peu de ruse pourrait faire l'affaire :

Code :

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

int ** pp = malloc( nRow * nCol * sizeof **pp );

Il faut vraiment utiliser la solution de Diogene ou de Trademark car celle-ci est fausse.


Tu va allouer un tableau de int * faisant k*la taille d'un int.
Déjà, simple logique, même si cela marcherais, comment veux-tu que le programme sache combien fait une colonne ou combien fait une ligne ?

Dès que tu va vouloir utiliser ce tableau :

pp[4][2];est équivalant à *(*(pp + 4) + 2); OR :

pp + 4est pointeur sur le cinquième élément de ton tableau

*(pp + 4) est le 5 ème élément de ton tableau qui est un pointeur d'int au contenu indéterminé

*(pp + 4) + 2 pointeur vers le 2ème élément du tableau pointé par *(pp + 4) c'est à dire un pointeur sur n'importe où dans la mémoire vu que *(pp + 4) est indéterminé

Donc *(*(pp + 4)+2) est un int qui est on ne sait où. Dès que tu feras une affectation, tu va toucher à de la mémoire qui ne t'appartient pas et tu risque la SEGFAULT



Pour éviter ce genre d'erreur, j'ai l'habitude de faire :

Code :

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

1
2
 
ptr = (T *)malloc(k * sizeof(T));

Avec k le nombre d'élément et T le type d'élément contenu. Le contenu de la parenthèse gauche doit être identique à celle de la parenthèse droite sauf qu'on lui rajoute un '*'. Si il y une erreur, le compilateur crise.

[takout]

En fait, j'avais pensé à ta solution Trademark mais j'avais lu que le faite de faire une multiplication à chaque fois qu'il faut accéder à un élément du tableaux c'était coûteux qu'il faut privilégié l'accès par pointeur.
Tu as une solution à me proposer pour remplacer les assert ?

[Neckara]

Si tu veux vraiment vérifier le code de retour du malloc tu peux faire :

Code :

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

1
2
3
4
5
6
7
 
tab=malloc(nrow*sizeof(double*));
if(tab == NULL)
{
        printf("...."); exit 1; //si l'erreur empêche ton programme d'atteindre son but premier
        return ...; //sinon tu renvois un code d'erreur que tu gèreras lors de l'appel de ta fonction.
}

Ainsi avec le return, après l'appel de ta fonction, tu pourras choisir entre afficher un message d'erreur, sortir proprement (en sauvegardant certains paramètre), exécuter une fonction alternative, cacher l'erreur.

Je plaisante en disant de cacher l'erreur, mais c'est une pratique qui est malheureusement un peu trop répandue...

[Trademark]

Comme le dit Neckara, tu peux vérifier le retour du malloc et afficher un message puis quitter. Généralement, quand un malloc échoue, tu ne pourras pas faire grand chose si ce n'est libérer de la mémoire autre part ou abandonner l'opération en cours pour faire autre chose... Ce qui n'est pas toujours possible.

j'avais lu que le faite de faire une multiplication à chaque fois qu'il faut accéder à un élément du tableaux c'était coûteux qu'il faut privilégié l'accès par pointeur.

Non ce n'est pas plus couteux, quelle est la différence entre faire :

Code :

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

tab[i] = tab[i-1]+ncol;

une soustraction et une addition.

Et

Code :

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

tab[i*ncol + j] = 0.0;

une multiplication et une addition... Franchement c'est des micro-optimisations complétement inutiles. Il vaut mieux allouer UNE fois un bloc de mémoire pour qu'il soit contigus et faire une multiplication en plus, que allouer plusieurs fois un bloc.

Tu parles d'opération sur les pointeurs, mais il faut bien garder à l'esprit qu'un pointeur c'est un entier sur 8 octets, donc ça ne change pas grand chose...

Si tu veux aller au fond des choses, je te conseille de lire :cpumemory.pdf.