Allocation dynamique d'un tableau de pointeurs vers une structure

Version imprimable

Voir 40 message(s) de cette discussion en une page

12/02/2007, 17h08
souviron34

Citation:

Envoyé par Médinoc

...si jamais on décide de changer le type d'un objet, il faut changer tous les casts.

;) si ton analyse et ta conception sont bien faits, à la limite tu peux rajouter des propriétés à l'objet, mais pas son type... :P
12/02/2007, 17h21
Médinoc
On n'est jamais à l'abri de la nouveauté.
- Il peut un jour être nécessaire de "scinder un type en deux"; voire en C++, de jouer avec l'héritage, s'apercevoir que les fonctions exposées par la classe mère sont insuffisantes pour les nouveaux besoins et qu'il faudra désormais travailler directement avec le type dérivé, etc.
- Ou bien, directement s'il est question d'un type entier, passer à un type entier plus grand;
- Ou encore partir d'un programme utilisant des char et le mettre à jour pour supporter unicode (passer aux wchar_t ou aux TCHAR sous Windows).
12/02/2007, 18h19
Thierry Chappuis

Citation:

Envoyé par Médinoc

J'ai tendance également à caster NULL pour lui donner un type fort, mais dans ce cas je conseille l'utilisation d'un define :

Code:

#define NULL_TRI ((Triangle *)NULL)

Voici une question de débutant, que je suis d'ailleurs, mais en quoi le fait de caster NULL ici lui confère un type fort. Lorsqu'un écrit:
Triangle *p_triangle = NULL;
On a un cast implicite (void *) -> (Triangle *) autorisé en C. Non?

Thierry
12/02/2007, 19h46
gl

Citation:

Envoyé par mujigka

On a un cast implicite (void *) -> (Triangle *) autorisé en C. Non?

Oui.

Le cast de NULL n'est pas obligatoire.
Mais il arrive parfois de rencontrer ce type de notation car certaines personnes y voient un interet documentaire (personellement je ne partage pas cette opinion).
J'ai egalement entendu parler, et Souviron le confirme dans son message, d'anciens compilateurs presentant des problemes de type sur NULL. Dans ce cas, le cast n'a plus de raison d'etre mais peut etre rencontre dans du code ancien ou ecrit par des personnes ayant pris cette habitude.

Citation:

Envoyé par gl

le cast n'a plus de raison d'etre mais peut etre rencontre dans du code ancien ou ecrit par des personnes ayant pris cette habitude.

Pas forcément si ancien que ça.... ;)

Exemple tiré de XFree-86 :

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
 
XFREE86_Region
XFREE86_XCreateRegion()
{
    XFREE86_Region temp;
 
    if (! (temp = ( XFREE86_Region )Xmalloc( (unsigned) sizeof( REGION ))))
	return (XFREE86_Region) NULL;
    if (! (temp->rects = ( BOX * )Xmalloc( (unsigned) sizeof( BOX )))) {
	Xfree((char *) temp);
	return (XFREE86_Region) NULL;
    }
 
..............
 
 
               if (! (dstrgn->rects = (BOX *)
		       Xrealloc((char *) dstrgn->rects,
				(unsigned) rgn->numRects * (sizeof(BOX))))) {
 
 
.............
 
	    if ((top != bot) && (nonOverlap1Func != (void (*)())NULL))
	    {
		(* nonOverlap1Func) (newReg, r1, r1BandEnd, top, bot);
	    }

et pour la date :

Code:

1
2
3
4
5
 
 
Copyright 1987, 1988, 1998  The Open Group
 
All Rights Reserved.

euhhh ;) :yaisse2:

12/02/2007, 20h56
gl
Citation:
Envoyé par souviron34

Pas forcément si ancien que ça.... ;)

Code:

1 2 3 4 Copyright 1987, 1988, 1998 The Open Group All Rights Reserved.
A l'echelle de l'informatique, 10 ans (voire 20 si ce code date de 87) c'est plutot ancien (et pre-C99).

Et puis on peu aussi rentre dans la seconde categorie : "ou ecrit par des personnes ayant pris cette habitude.".
Sans compter sur les personnes qui trouvent une valeur documentaire a ce genre de pratique.
12/02/2007, 21h11
Médinoc

Citation:

Envoyé par mujigka

Voici une question de débutant, que je suis d'ailleurs, mais en quoi le fait de caster NULL ici lui confère un type fort. Lorsqu'un écrit:
Triangle *p_triangle = NULL;
On a un cast implicite (void *) -> (Triangle *) autorisé en C. Non?

Oui, mais on n'a pas de cast implicite (Triangle *) -> (NimporteQuoi *) ;)
Donc oui, le cast est principalement à des fins documentaires, et pour être sûr qu'on sait toujours de quoi on parle, ce qu'on passe (ou plutôt ne passe pas) à une fonction, etc.
13/02/2007, 00h08
souviron34

Citation:

Envoyé par gl

A l'echelle de l'informatique, 10 ans (voire 20 si ce code date de 87) c'est plutot ancien (et pre-C99).

Et puis on peu aussi rentre dans la seconde categorie : "ou ecrit par des personnes ayant pris cette habitude.".
Sans compter sur les personnes qui trouvent une valeur documentaire a ce genre de pratique.

Absolument d'accord avec la deuxième partie..

Cependant en ce qui concerne les "10 ans (voire 20 ...) etc.." , je ne suis pas d'accord.. J'ai démarré un débat sur le forum général, mais personne n'a répondu. Mais je pense que les décideurs et chefs de projets en info font un peu aussi du "jeunisme", et suivent d'un peu trop près la mode...

Je viens d'un milieu où les projets peuvent mettre 30 ans à être écrits et peuvent avoir une durée de vie de 50 ans (voir la station spatiale orbitale Freedom) : 80 000 programmeurs de 50 pays pendant 25 ans. Durée de vie prévue en orbite : minimum 40 ans. 10 ans uniquement consacré à rédiger les normes de programmation pour chaque langage.

Je respecte la pensée, et je tente de m'inscire dans la même lignée. Mon code devrait faire une fonctionalité que l'informatique peut faire mieux et plus rapidement que l'humain, le déchargeant ainsi d'une partie souvent fastidieuse de son travail. Cependant j'aime à croire que ce que je fais ne vas pas partir à la poubelle dans les 3 ans.... Mais je me fais peut-être des illusions :cry:

Plus prosaiquement, pour ne citer que quelques exemples (et en remontant dans le temps) qui ont toujours leurs usages aujourd'hui :

HTTP : code C écrit en 1992

XWindow : code C écrit entre 1979 et 1984

.... : (je me souviens plus le nom là tout de suite) : bibliothèque de maths du CERN code Fortran écrit entre 1963 et 1978 (environ 20 millions de lignes)

(si ça vous intéresse je vous retrouverai le nom demain).

En résumé, oui au progrès, non à l'obscolescence (?) à tout prix....

PS: malgré tous les progrès techniques dans tous les matériaux, un ébéniste qui fait une armoire en bois, son armoire dure beaucoup plus longtemps qu'une amoire IKEA ;) (et sans compter (je suis dans le Sud :) ) les acqueducs romains, un peu plus solides que les tours de la Défense...)
13/02/2007, 00h45
Thierry Chappuis

Citation:

Envoyé par Médinoc

Oui, mais on n'a pas de cast implicite (Triangle *) -> (NimporteQuoi *) ;)
Donc oui, le cast est principalement à des fins documentaires, et pour être sûr qu'on sait toujours de quoi on parle, ce qu'on passe (ou plutôt ne passe pas) à une fonction, etc.

C'est vrai! Merci Médinoc...

Thierry
13/02/2007, 08h56
Emmanuel Delahaye
Citation:
Envoyé par souviron34

reprenons calmement l'exemple :

Code:

1 2 typedef struct _Triangle {
Pas portable. Ce nom est réservé à l'implémentation :

http://emmanuel-delahaye.developpez....htm#id_reserve

Selon mes regles de codage, ça donnerait ça :
Code:

1 2 3 4 5 6 7 8 9 10 11 typedef struct triangle { int s1; int s2; int s3; struct triangle *p_next; struct triangle *p_prev; } triangle_s;

Citation:

Envoyé par souviron34

Code:

1
2
3
4
5
6
7
8
9
10
11
 
  Triangle    *Triangles = (Triangle *)NULL ;
  Triangle    *elt = (Triangle *)NULL ;
  Triangle    *next = (Triangle *)NULL ;
 
  ......
 
	    elt = (Triangle *) calloc (1, sizeof(Triangle) );
	    if ( elt == (Triangle *)NULL )
	      {
		if ( next != (Triangle *)NULL )

Ca sert à quoi tous ces cast ?

Code:

1
2
3
4
5
6
7
8
9
10
11
 
  Triangle    *Triangles = NULL;
  Triangle    *elt = NULL ;
  Triangle    *next = NULL ;
 
  ......
 
	    elt = calloc (1, sizeof(Triangle) );
	    if ( elt == NULL )
	      {
		if ( next != NULL )

D'autre part, calloc() (all-bit-to-zero) n'est pas une manière portable d'initialiser les éléments d'une structure à 0.

13/02/2007, 09h16
Médinoc

Les casts de NULL, on en a discuté plus haut (fins documentaires, mais devrait être plus centralisé selon moi).

Celui de calloc() par contre est inapproprié.

Citation:
Envoyé par souviron34
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 XFREE86_Region XFREE86_XCreateRegion() { XFREE86_Region temp; if (! (temp = ( XFREE86_Region )Xmalloc( (unsigned) sizeof( REGION )))) return (XFREE86_Region) NULL; if (! (temp->rects = ( BOX * )Xmalloc( (unsigned) sizeof( BOX )))) { Xfree((char *) temp); return (XFREE86_Region) NULL; } Copyright 1987, 1988, 1998 The Open Group All Rights Reserved.
Bah, du mauvais code ou du code écrit par des gens qui mélangent C et C++, on en trouve partout... Ca ne sert à rien de citer du code open source. C'est probablement du code qui fonctionne, mais ça n'a jamais été une référence en matière de codage. En quelques lignes :

déclaration de la fonction non prototypale (manque void)
pointeurs cachés
définitions redondantes : XFREE86_Region est visiblement *REGION
manque d'homogénéité : cast sans *, cast avec *...
casts inutiles
! au lieu de == NULL
affectaton dans un if()
return multiples

je m'arrête là, parce que pour 10 lignes de code, je trouve que ça fait beaucoup...

bref, ce code ne passe pas le moindre contrôle de qualité en entreprise.

13/02/2007, 09h49
Emmanuel Delahaye

Citation:

Envoyé par Médinoc

Les casts de NULL, on en a discuté plus haut (fins documentaires, mais devrait être plus centralisé selon moi).

Je ne vois pas ce que ça documente. Et puis NULL est compatible avec tous les types pointeur sur objet, alors qu'est-ce que change ?
13/02/2007, 09h50
crocodilex

Citation:

Envoyé par Emmanuel Delahaye

En plus, il y a un bug fonctionnel. Si le 2ème xmalloc() echoue, la première allocation n'est pas libérée... Horrible. (Les returns multiples, ça tue...)

Apparement si, la première allocation est bien libérée.
13/02/2007, 09h55
Emmanuel Delahaye

Citation:

Envoyé par crocodilex

Apparement si, la première allocation est bien libérée.

:oops: Exact, c'est tellement ilisible que je ne l'avais pas vu (on va dire ça comme ça :aie: )
13/02/2007, 10h08
Médinoc

Citation:

Envoyé par Emmanuel Delahaye

Et puis NULL est compatible avec tous les types pointeur sur objet, alors qu'est-ce que change ?

Comme dit plus haut, c'est justement le problème.
Utiliser des #define avec un NULL casté donne des NULL typés.
Bien sûr, caster directement dans chaque utilisation est stupide à mon goût...
13/02/2007, 10h17
Emmanuel Delahaye

Citation:

Envoyé par Médinoc

Comme dit plus haut, c'est justement le problème.

J'ai toujours pas compris en quoi c'était un problème. Tu peux donner un exemple de problème ?

Citation:

Utiliser des #define avec un NULL casté donne des NULL typés.
Bien sûr, caster directement dans chaque utilisation est stupide à mon goût...

A quoi ça sert des NULL typés ? Dans un contexte pointeur, NULL a la même sémantique quelque soit le type, je ne vois pas contre quelle erreur on cherche à se défendre...

Je ne suis pas contre, mais je veux juste qu'on m'explique.

Je ne connais personnellement qu'un cas où il faut mettre un cast à NULL, c'est quand c'est un paramètre de fonction variadic, parce que dans ce cas, le contexte pointeur n'est pas implicite.

Code:

printf ("%p\n", (void *) NULL);
13/02/2007, 10h34
Médinoc

En effet, je viens de voir la faille de mon raisonnement.
Je pensais utiliser des NULL typés pour sans cesse se rappeler qu'un paramètre à NULL était supposé être un pointeur de tel type, garder le type de variable à l'esprit en permanence, mais cela induit en fait un coût de maintenance supplémentaire si un type est modifié (comme les casts, en fait).

Donc en fait, utiliser des NULL typés est absolument inutile, mon raisonnement dessus vient de s'écrouler.

Edit : AH SI ! Je me souviens pourquoi j'avais fait ça, c'est à cause du C++, et cela évitait tout risque d'affecter un NULL à autre chose qu'un pointeur (en C, NULL est la plupart du temps (mais non-garanti) déjà un void*, alors qu'en C++, c'est généralement un bète 0). Je ne supporte pas ceux qui utilisent allègrement 0 pour NULL, voire l'inverse en C++.
13/02/2007, 15h37
souviron34

bon.. Je veux bien que C99 prenne en compte certaines choses.

Mais certaines choses sont dans la définition même de C, car MACHINE-dépendantes.

Je vous place donc ici quelques extraits de K&R pour :

- les cast
- les sizeof de variable ou de type...

Et de plus, je peux vous assurez que pour les free, si vous comptez sur le fait qu'un free(NULL) ne fera rien, eh bien bonne chance.....

http://cjoint.com/?cnpKxor2Qp

Voir 40 message(s) de cette discussion en une page