gestion mémoire sur plusieurs malloc

Version imprimable

Bonjour,

Je voudrais savoir si vous avez des methodes pour gérer les malloc et leurs tests si ils echouent.

Voici un exemple que j'ai écrit pour 3 pointeurs a allouer. Il me semble que ce code est "sur" dans le sens ou on ne peut pas perdre de mémoire, mais on voit que ca peut devenir vite lourd à gerer, surtout si on en a plus que 3, mais c'est la manière la plus simple et concise que j'ai trouvé pour l'instant :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 int * a, *b; int ** c; a = malloc(taille); b = malloc(taille); c = malloc(taille2); if(a == NULL || b == NULL || c == NULL) { free(a); free(b); free(c); return -1; } //je met tout à null pour pouvoir faire un free sur tous au cas ou un échoue. for(i = 0 ; i < taille2 ; i++) { c[i] = NULL; } for(i = 0 ; i < taille2 ; i++) { c[i] = malloc(taille); if( c[i] == NULL) { free(a); free(b); for(i = 0 ; i < taille2 ; i++) { free(c[i]); } free(c); return -1; } } //ouf tous les mallocs ont fonctionnés :roll: //on peut maintenant ecrire le reste de la fonction sans oublier de faire un free pour tous les pointeurs a la fin

Code:

1 2 3 4 5 6 7 8 9 10 a = malloc(taille); b = malloc(taille); c = malloc(taille2); if(a == NULL || b == NULL || c == NULL) { free(a); free(b); free(c); return -1; }
Ceci est correct. On peut faire free(NULL) en toute sécurité

Tu peux te dispenser de la mise à NULL préalable des c[i] :
Code:

1 2 3 4 5 6 7 ... c[i] = malloc(taille); if( c[i] == NULL) { ... for(j = 0 ; j < i ; j++) free(c[j]); ....

Arrete de poster n'importe quoi, ou bien pose des questions !!!!

Ton code cointient au moins 4 raisons de crasher sans avertissement,....

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
int * a, *b;
int ** c;
 
a = malloc(taille);
b = malloc(taille);
c = malloc(taille2);
 
if(a == NULL || b == NULL || c == NULL) {
/**** OU SONT LES TESTS POUR SAVOIR LEQUEL EST NULL ??? ****/
	free(a);
	free(b);
	free(c);
	return -1;
}
 
//je met tout à null pour pouvoir faire un free sur tous au cas ou un échoue.
for(i = 0 ; i < taille2 ; i++) {
	c[i] = NULL;
}
 
for(i = 0 ; i < taille2 ; i++) {
	c[i] = malloc(taille);
	if( c[i] == NULL) {
		free(a);
		free(b);
/**** DE i A taille2 IL N'Y A RIEN D'ALLOUE !!!!!! ****/
		for(i = 0 ; i < taille2 ; i++) {
			free(c[i]);
		}
		free(c);
		return -1;
	}
}
 
//ouf tous les mallocs ont fonctionnés :roll:
 
//on peut maintenant ecrire le reste de la fonction sans oublier de faire un free pour tous les pointeurs a la fin

Une bonne maniere de faire serait :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
int j ;
int * a=NULL, *b=NULL;
int ** c=NULL;
 
a = malloc(taille);
b = malloc(taille);
c = malloc(taille2);
 
if(a == NULL || b == NULL || c == NULL) {
         if ( a != NULL )
	free(a);
         if ( b != NULL )
	free(b);
         if ( c != NULL )
	free(c);
	return -1;
}
 
//je met tout à null pour pouvoir faire un free sur tous au cas ou un échoue.
for(i = 0 ; i < taille2 ; i++) {
	c[i] = NULL;
}
 
for(i = 0 ; i < taille2 ; i++) {
	c[i] = malloc(taille);
	if( c[i] == NULL) {
		free(a);
		free(b);
                         if ( i != 0 )
  		  for(j = (i-1) ; j >= 0 ; j--) {			free(c[j]);
		}
		free(c);
		return -1;
	}
}
 
//ouf tous les mallocs ont fonctionnés :roll:
 
//on peut maintenant ecrire le reste de la fonction sans oublier de faire un free pour tous les pointeurs a la fin

21/02/2008, 17h46
contremaitre

Citation:

Envoyé par souviron34

Arrete de poster n'importe quoi, ou bien pose des questions :evilred:

Ton code contient au moins 4 raisons de crasher sans avertissement,....

Pas la peine de s'énerver... mon code ne crashe pas car il n'y a pas besoin de tester lequel est à NULL vu qu'on peut faire free(NULL) (cf man free)

Meme explication pour ta deuxième phrase en rouge -> j'avais initialisé a null

Quand à "ou bien pose des questions", j'en ai posé une : c'est comment rendre ca moins lourd à gerer... je demande vos méthode pour ce genre de choses...

Tu a sans doute mal lu mon post :(
21/02/2008, 17h50
souviron34

Citation:

Envoyé par diogene

On peut faire free(NULL) en toute sécurité

pas sur tous les systemes... HPUX et SunOs crashent... (enfin crashaient il y a 6 ans)
21/02/2008, 17h53
souviron34
et pour eviter de faire :
Code:

1 2 3 4 for(i = 0 ; i < taille2 ; i++) { c[i] = NULL; }
il suffirait de faire

Code:

c = calloc ( taille2, sizeof(int *) );

Et d'ailleurs tes pointeurs sont declares comme des entiers (pointeurs), mais tu alloues des bytes...
21/02/2008, 17h53
contremaitre

J'ai toujours lu dans man free

Citation:

Si ptr est NULL, aucune tentative de libération n'a lieu.

donc j'utilise cette propriété.
Si ça ne marche pas sur tous les sytemes, je ne le savais pas, mais ça change pas trop ma question d'origine qui est :

Je voudrais savoir si vous avez des methodes pour gérer les malloc et leurs tests si ils echouent.
21/02/2008, 17h55
contremaitre

Citation:

Envoyé par souviron34

Et d'ailleurs tes pointeurs sont declares comme des entiers (pointeurs), mais tu alloues des bytes...

Oui mais c'etait pour simplifier le code je ne fait pas ca dans un vrai code.
J'aurai fait a = malloc (taille*sizeof(*a))
Cet exemple était pour illustrer la lourdeur d'allouer plusieurs zones memoires sans risquer de fuites en cas d'echec.
21/02/2008, 17h57
souviron34

faire du code resistant a tout signifie en general au moins 50% de code pour gerer les erreurs !!!!!
21/02/2008, 17h57
Médinoc

Un système qui crashe sur un free(NULL) ne respecte pas la norme du C ANSI.

Donc, sur tout système au moins respectueux du standard C90 (voire C89), free(NULL) est garanti ne pas crasher.
21/02/2008, 18h02
diogene

Citation:

Envoyé par souviron34

pas sur tous les systemes... HPUX et SunOs crashent... (enfin crashaient il y a 6 ans)

Je me réfère aux bons auteurs :

n1124 me dit

Citation:

7.20.3.2 The free function
Synopsis
1 #include <stdlib.h>
void free(void *ptr);
Description
2 The free function causes the space pointed to by ptr to be deallocated, that is, made
available for further allocation. If ptr is a null pointer, no action occurs....

alors, moi je la crois!:P
21/02/2008, 18h05
contremaitre

Citation:

Envoyé par souviron34

faire du code resistant a tout signifie en general au moins 50% de code pour gerer les erreurs !!!!!

oui, mais bon je me dit qu'il doit bien y avoir une maniere plus simple de gerer ce genre de cas.
Car si on a n zones mémoire à allouer (dont certaines avec des allocations d'allocations), alors pour gerer la liberation des zones non alloués si ca foire en plein milieu, c'est pas 50% mais 99% de code pour gerer les erreurs si n est assez grand.
21/02/2008, 18h11
souviron34

Citation:

Envoyé par pasdeface

oui, mais bon je me dit qu'il doit bien y avoir une maniere plus simple de gerer ce genre de cas.
Car si on a n zones mémoire à allouer (dont certaines avec des allocations d'allocations), alors pour gerer la liberation des zones non alloués si ca foire en plein milieu, c'est pas 50% mais 99% de code pour gerer les erreurs si n est assez grand.

si tu en as autant et que ce n'est pas en tableau, alors c'est sans doute une erreur de conception..

Sinon eh bien oui, cela peut etre 99% du code d'une fonction...
21/02/2008, 19h32
souviron34

Citation:

Envoyé par Médinoc

Un système qui crashe sur un free(NULL) ne respecte pas la norme du C ANSI.

Donc, sur tout système au moins respectueux du standard C90 (voire C89), free(NULL) est garanti ne pas crasher.

Citation:

Envoyé par diogene

Je me réfère aux bons auteurs :

n1124 me dit

alors, moi je la crois!:P

essaye sur un HPUX 10.2 ... ;) ou un serveur HP K(230 ??), ou une station SGI Irix Indigo de 1997.. ;)
21/02/2008, 22h15
orfix
Citation:
Envoyé par souviron34

et pour eviter de faire :

Code:

1 2 3 4 for(i = 0 ; i < taille2 ; i++) { c[i] = NULL; }

il suffirait de faire

Code:

c = calloc ( taille2, sizeof(int *) );

Et d'ailleurs tes pointeurs sont declares comme des entiers (pointeurs), mais tu alloues des bytes...
calloc ne garantis pas la mise à NULL ...enfin c'est ce que j'ai compris en lisant les nombreux postes traitant du "all bits zero" et de cette fameuse "trap representation" ....peut être que je me trompe c'est plus une confirmation que j'attends :aie:

Citation:

Envoyé par souviron34

Une bonne maniere de faire serait :

Code:

1
2
3
4
5
6
7
8
int j ;
int * a=NULL, *b=NULL;
int ** c=NULL;
 
a = malloc(taille);
b = malloc(taille);
c = malloc(taille2);

Euh, il n'y a pas de différence entre

Code:

1
2
3
4
 
T *p;
 
   p = malloc(...);

Code:

1
2
3
4
 
T *p = NULL;
 
   p = malloc(...);

Code:

1
2
 
T *p = malloc(...);

Personnellement, la 3ème forme a ma préférence...

Citation:

Envoyé par souviron34

pas sur tous les systemes... HPUX et SunOs crashent... (enfin crashaient il y a 6 ans)

Non conformité au langage C ? C'est grave...

Citation:

Envoyé par souviron34

faire du code resistant a tout signifie en general au moins 50% de code pour gerer les erreurs !!!!!

Citation:

Envoyé par pasdeface

Je voudrais savoir si vous avez des methodes pour gérer les malloc et leurs tests si ils echouent.

Dans un premier temps, je fais comme ça :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
 
#include <stdlib.h>
#include <assert.h>
 
int main (void)
{
   int taille = 3;
   int taille2 = 4;
 
   int *a = malloc (taille * sizeof *a);
   if (a != NULL)
   {
      int *b = malloc (taille * sizeof *b);
      if (b != NULL)
      {
         int **c = malloc (taille2 * sizeof *c);
         if (c != NULL)
         {
 
/* je met tout à null pour pouvoir faire
un free sur tous au cas ou un échoue. */
            {
               int i;
               for (i = 0; i < taille2; i++)
               {
                  c[i] = NULL;
               }
            }
 
            {
               int err = 0;
               {
                  int i;
                  for (i = 0; !err && i < taille2; i++)
                  {
                     c[i] = malloc (taille * sizeof *c[i]);
                     if (c[i] == NULL)
                     {
                        err = 1;
                     }
                  }
               }
               if (err)
               {
                  /* tout liberer */
                  int i;
                  for (i = 0; i < taille2; i++)
                  {
                     free (c[i]);
                  }
                  free (c), c = NULL;
                  free (b), b = NULL;
                  free (a), a = NULL;
               }
            }
 
            /* usage */
 
            /* liberation */
            {
               int i;
               for (i = 0; i < taille2; i++)
               {
                  free (c[i]);
               }
               free (c), c = NULL;
            }
         }
         free (b), b = NULL;
 
         assert (c == NULL);
      }
      free (a), a = NULL;
 
      assert (b == NULL);
   }
   assert (a == NULL);
 
   return 0;
}

Mais dans la vraie vie, ce serait évidemment différent :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
 
/* main.c */
#include <stdlib.h>
 
#include "x.h"
 
int main (void)
{
   /* creation */
   struct x *p = x_create (3, 4);
 
   if (p != NULL)
   {
      /* usage */
 
      /* liberation */
      x_delete (p);
   }
   return 0;
}

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
 
/* x.h */
#ifndef H_ED_X_20080222035637
#define H_ED_X_20080222035637
 
struct x;
 
struct x *x_create(int taille, int taille2);
void x_delete(struct x *self);
 
#endif /* guard */
 
/* Guards added by GUARD (c) ED 2000-2005 Jan 17 2005 Ver. 1.7 */

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
 
/* x.c */
#include "x.h"
 
#include <stdlib.h>
 
struct x
{
   int *a;
   int *b;
   int **c;
   int taille2;
};
 
struct x *x_create (int taille, int taille2)
{
   struct x *self = malloc (sizeof *self);
   if (self != NULL)
   {
      /* tout a 0 */
      {
         static const struct x z = { 0 };
         *self = z;
      }
 
      self->a = malloc (taille * sizeof *self->a);
      if (self->a != NULL)
      {
         self->b = malloc (taille * sizeof *self->b);
         if (self->b != NULL)
         {
            self->c = malloc (taille2 * sizeof *self->c);
            if (self->c != NULL)
            {
 
/* je met tout à null pour pouvoir faire
un free sur tous au cas ou un échoue. */
               {
                  int i;
                  for (i = 0; i < taille2; i++)
                  {
                     self->c[i] = NULL;
                  }
               }
 
               {
                  int err = 0;
                  {
                     int i;
                     for (i = 0; !err && i < taille2; i++)
                     {
                        self->c[i] = malloc (taille * sizeof *self->c[i]);
                        if (self->c[i] == NULL)
                        {
                           err = 1;
                        }
                     }
                  }
                  if (err)
                  {
                     x_delete (self), self = NULL;
                  }
                  else
                  {
                     self->taille2 = taille2;
                  }
               }
            }
            else
            {
               x_delete (self), self = NULL;
            }
         }
         else
         {
            x_delete (self), self = NULL;
         }
      }
      else
      {
         x_delete (self), self = NULL;
      }
   }
   return self;
}
 
void x_delete (struct x *self)
{
   if (self != NULL)
   {
      if (self->c != NULL)
      {
         /* tout liberer */
         int i;
         for (i = 0; i < self->taille2; i++)
         {
            free (self->c[i]);
         }
         free (self->c);
      }
      free (self->b);
      free (self->a);
      free (self);
   }
}

22/02/2008, 08h33
contremaitre

merci
06/03/2008, 14h44
contremaitre

Me revoilà.

Emmanuel Delahaye, ton exemple me plait beaucoup mais j'ai du mal a le comprendre.

Pourquoi les membres de struct x sont défnis dans x.c ?
Comment on peut accéder aux membres de p (de type struct x) dans le main ?

merci
06/03/2008, 15h22
Médinoc

Justement, avec un Type Abstrait de Données (TAD), on n'y accède pas. On peut seulement appeler des fonctions qui y accèdent, et qui sont elles aussi définies dans x.c.
06/03/2008, 15h24
contremaitre

ha, c'est un équivalent des classes en c++?
06/03/2008, 15h29
Médinoc

Plus ou moins. Pas exactement, mais il y a quelques similitudes.
06/03/2008, 17h05
Emmanuel Delahaye

Citation:

Envoyé par pasdeface

Emmanuel Delahaye, ton exemple me plait beaucoup mais j'ai du mal a le comprendre.

http://emmanuel-delahaye.developpez.com/tad.htm
06/03/2008, 17h10
contremaitre

merci
07/03/2008, 22h40
corrector

Citation:

Envoyé par ssmario2

calloc ne garantis pas la mise à NULL ...enfin c'est ce que j'ai compris en lisant les nombreux postes traitant du "all bits zero" et de cette fameuse "trap representation" ....peut être que je me trompe c'est plus une confirmation que j'attends :aie:

Et tu as parfaitement raison : la représentation d'un pointeur nul n'est pas forcément tous les bits à 0.
08/03/2008, 08h48
Thierry Chappuis

Citation:

Envoyé par ssmario2

calloc ne garantis pas la mise à NULL ...enfin c'est ce que j'ai compris en lisant les nombreux postes traitant du "all bits zero" et de cette fameuse "trap representation" ....peut être que je me trompe c'est plus une confirmation que j'attends :aie:

Tu as raison, rien ne garantit que NULL est représenté avec tous les bits à zéro. Dans ce contexte, il n'est pas possible de se fier à calloc() pour initialiser un tableau de pointeur ou un tableau de flottants à une valeur nulle (NULL ou 0.0 respectivement). C'est en revanche OK pour les entiers.

EDIT: Oups, désolé corrector, ça m'apprendra à répondre sans avoir lu le fil jusqu'à la fin

Thierry
08/03/2008, 11h00
Emmanuel Delahaye

Citation:

Envoyé par Thierry Chappuis

Dans ce contexte, il n'est pas possible de se fier à calloc() pour initialiser un tableau de pointeur ou un tableau de flottants à une valeur nulle (NULL ou 0.0 respectivement). C'est en revanche OK pour les entiers.

Pour char, et les entiers non signés, oui. Pour les autre type entiers, C99 admet la possibilité d'une 'trap représentation' et ne dit pas que all-bit-to-zero ne peut pas en être une. (désolé pour les négations...)
08/03/2008, 12h36
orfix

Merci pour vos confirmations !

J'aimerais avoir une petite explication sur ce qu'est réellement "une trap representation" ainsi que "le bit padding" ...:oops:

Merci !
08/03/2008, 13h11
Emmanuel Delahaye

Citation:

Envoyé par ssmario2

J'aimerais avoir une petite explication sur ce qu'est réellement "une trap representation"

En gros, une combinaison de bits interdite provoquant une exception (trap ou 'piège').

Citation:

ainsi que "le bit padding"

Je connais le bit stuffing utilisé en codage numérique réseau et le byte padding qui est le remplissage placé entre les éléments d'une structure pour garantir l'alignement...
08/03/2008, 13h19
diogene

n1124 :

Citation:

6.2.6.2 Integer types
.....
5 The values of any padding bits are unspecified.45) A valid (non-trap) object representation of a signed integer type where the sign bit is zero is a valid object representation of the corresponding unsigned type, and shall represent the same value. For any integer type, the object representation where all the bits are zero shall be a representation of the value zero in that type.
08/03/2008, 13h25
corrector
Citation:

Envoyé par ssmario2

J'aimerais avoir une petite explication sur ce qu'est réellement "une trap representation" ainsi que "le bit padding"

trap representation : état mémoire d'un objet de type T :
1. qui ne correspond pas à la représentation d'une valeur de T,
2. et qui, s'il est interprété par le processeur comme étant du type T, provoquera une erreur
Par exemple, sur les certaines machines représentant les entiers signés en signe-magnitude, la représentation "zéro négatif" peut être une trap representation. Une variable int non initialisée pourra avoir un tel état. Tenter de la lire provoquera une exception processeur (= trap).

Plus répandu de nos jours : sur un processeur x86, charger un pointeur non valide dans un registre d'adresse peut provoquer une erreur.

unsigned char n'a pas de trap representation, et permet d'examiner la mémoire; mais signed char et char peuvent avoir des "trap representation"!

padding bits : bits appartenant aux bytes d'un objet (sizeof(T) bytes pour un objet de type T), mais qui ne contribuent pas à la représentation de la valeur de l'objet : quel que soit l'état de ces bits, la valeur représentée est la même.

S'il un type T a des bits de padding (= remplissage/rembourrage), deux objets de type T de même valeur n'auront pas forcément la même représentation; si a et b sont de type T, on peut avoir la propriété :

a == b && memcmp (&a, &b, sizeof a) != 0

Copier une variable d'un tel type pourra soit copier tous les bits y compris ceux de padding, soit ne pas modifier les bits de padding de la cible, soit faire n'importe quoi sur ces bits.

Ce qui implique qu'on ne peut pas, en général, comparer la valeur des objets avec memcmp.

char, et ses variantes signées et non-signées, ne peuvent pas avoir de padding bits.
08/03/2008, 13h40
gl

Citation:

Envoyé par corrector

char, et ses variantes signées et non-signées, ne peuvent pas avoir de padding bits.

Pour unsigned char, je suis d'acord. Par contre je n'ai rien trouve qui empeche signed char d'avoir des padding bits.

Citation:

Envoyé par n1124 §6.2.6.2

1 - For unsigned integer types other than unsigned char, the bits of the object representation shall be divided into two groups: value bits and padding bits (there need not be any of the latter). If there are N value bits, each bit shall represent a different power of 2 between 1 and 2N−1, so that objects of that type shall be capable of representing values from 0 to 2N − 1 using a pure binary representation; this shall be known as the value representation. The values of any padding bits are unspecified.44)

2 - For signed integer types, the bits of the object representation shall be divided into three groups: value bits, padding bits, and the sign bit.
08/03/2008, 14h01
orfix

Citation:

Envoyé par corrector

S'il un type T a des bits de padding (= remplissage/rembourrage), deux objets de type T de même valeur n'auront pas forcément la même représentation; si a et b sont de type T, on peut avoir la propriété :

a == b && memcmp (&a, &b, sizeof a) != 0

je vois mieux pourquoi la comparaison bit à bit est très déconseillée :cfou:

Merci à tous
27/03/2008, 10h02
contremaitre
Bonjour,

est ce que ça pose un problème de déclarer
Code:

1 2 3 4 5 6 7 8 struct x { int *a; int *b; int **c; int taille2; };
dans x.h au lieu de x.c, pour ensuite dans le main faire p->a pour accéder à a plutôt que de devoir créer une fonction x_geta pour chaque tableau (a,b,c etc...)

Car j'ai besoin de ces tableaux pour les donner à d'autres fonctions. Je ne peux pas me permettre de faire des fonctions dans le TAD (comme le dit médinoc, ou comme expliqué ici http://emmanuel-delahaye.developpez.com/tad.htm) qui elles accèdent aux données car je devrais alors réécrire tous mes algos de traitement qui prennent en entrée un int * par exemple.
27/03/2008, 11h23
Thierry Chappuis

Cela ne pose à priori pas de problème. Tout dépend en fait de quel degré d'encapsulation des données tu désires avoir. Si le code client accède directement aux champs de la structure, tout changement ultérieur de cette structure pourrait devenir difficile à mettre en oeuvre.

Thierry
27/03/2008, 11h28
contremaitre

en fait ce qui est surtout important pour moi, c'est de faciliter l'allocation (et désallocation) mémoire de mes tableaux.

Et mettre ces fonctions dans une fichier séparé, je trouve ça pratique.
Donc si je peux aussi accéder aux membres de ma structure directement c'est ce dont j'ai besoin pour ce problème.
27/03/2008, 11h30
Thierry Chappuis

Citation:

Envoyé par pasdeface

en fait ce qui est surtout important pour moi, c'est de faciliter l'allocation (et désallocation) mémoire de mes tableaux.

Et mettre ces fonctions dans une fichier séparé, je trouve ça pratique.
Donc si je peux aussi accéder aux membres de ma structure directement c'est ce dont j'ai besoin pour ce problème.

En quoi le fait de rendre la structure interne de ton TAD public facilite l'allocation et la désallocation de mémoire?

Thierry
27/03/2008, 11h36
contremaitre

Citation:

Envoyé par Thierry Chappuis

En quoi le fait de rendre la structure interne de ton TAD public facilite l'allocation et la désallocation de mémoire?

Thierry

Non, ce qui facilite la (dés)allocation, c'est d'avoir des fonctions comme x_create ou x_delete qui s'en occupent.

Par contre le fait de rentre la structure publique facilite l'accés à mes tableaux pour les passer à mes différents algos qui prennent en paramètre un int* par exemple.
Sinon, pour chaque tableau il me faudrait créer une fonction get
27/03/2008, 13h47
contremaitre
Citation:
Envoyé par Emmanuel Delahaye

Code:

1 2 3 4 5 6 /* tout a 0 */ { static const struct x z = { 0 }; *self = z; }
Est ce que ça initialise les pointeurs à NULL de faire ça?
(les pointeurs à l'intérieur de la structure je parle)
27/03/2008, 13h48
Médinoc

Oui.
27/03/2008, 13h51
Thierry Chappuis

Citation:

Envoyé par pasdeface

Est ce que ça initialise les pointeurs à NULL de faire ça?

Ca initialise tous les champs de la structure à la valeur nulle adéquate i.e. NULL pour un pointeur, 0 pour un entier, 0.0 pour un flottant de type double, etc.

Thierry