Héritage et polymorphisme en C

Bonjour,

Dans son tutoriel sur l'héritage en C, http://chgi.developpez.com/c/heritage/ , CGi utilise la méthode suivante:
Quand on veut qu'une structure hérite d'une autre structure, le début de la classe fille doit être le même que celui de la classe mère. Les nouveaux attributs sont ajoutés à la fin.

Exemple:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13

struct Mere { int a; int b; };   struct Fille { // membres de Mere int a; int b; // membres de Fille int c; }

---

Il utilise le polymorphisme:

Code:

---

1 2 3 4 5

struct Mere *m; struct Fille f = { 1, 2, 3 };   m = (struct Mere *) &f; // utiliser m->a et m->b

---

Le C garantit que le premier élément de la structure est à l'addresse 0, donc ça doit marcher pour "a" tout le temps.
Ma question est: est-ce que pour les autres éléments de la structure, ça marchera quelque soit le type et le nombre d'attributs, et quelque soit le compilateur ? Parce que le compilateur peut également ajouter des octets de remplissage (padding).

Pourquoi ne pas passer au C++ ?

Sinon, il y a les struct, les énum. Et ne pas utiliser de variables globales.

Je te déconseille ce genre de code. Si les optimisations de compilation en vectorisation sont utilisées, ton code ne fonctionnera probablement plus.
Exemple avec xlC, le compilateur IBM AIX :

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

#include <stdio.h> #include <stdlib.h>   typedef struct { int a; int b; } premier;   typedef struct { int a; int b; char c; } second;   int main( void ) { second s; s.a = 10; s.b = 40; s.c = 2; premier * p = (premier *)((void*)& s); printf( "a=%d, b=%d\n", p->a, p->b ); exit( 0 ); }

---

Ce code fonctionne très bien en compilant avec xlC sans aucune option.
Par contre, en compilant avec : xlc -O3 -qarch=pwr6 -qsimd=auto mon_prog.c, l'affichage devient faux par rapport à ce qu'on attend.

Citation:

---

Quand on veut qu'une structure hérite d'une autre structure, le début de la classe fille doit être le même que celui de la classe mère

---

Je ne trouve pas çà très malin... Si tu dois modifier ton objet mère, tu dois faire la même modif sur tous les objet qui en hérite...

Je préfère comme ca:

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

#include <stdio.h> #include <stdlib.h>   typedef struct { int a; int b; } premier;   typedef struct { premier p; char c; } second;   int main( void ) { second s; s.p.a = 10; s.p.b = 40; s.c = 2; premier * p = &s.p; printf( "a=%d, b=%d\n", p->a, p->b ); exit( 0 ); }

---

Citation:

---

Envoyé par dinobogan

Si les optimisations de compilation en vectorisation sont utilisées, ton code ne fonctionnera probablement plus.

---

Probablement car la règle de l’aliasing est violée.

Citation:

---

Envoyé par dinobogan

Par contre, en compilant avec : xlc -O3 -qarch=pwr6 -qsimd=auto mon_prog.c, l'affichage devient faux par rapport à ce qu'on attend.

---

Par curiosité, ça affiche quoi ?

Citation:

---

Envoyé par mith06

Je ne trouve pas çà très malin... Si tu dois modifier ton objet mère, tu dois faire la même modif sur tous les objet qui en hérite...

---

Yep, c’est vraiment un handicap pour quand le code évolue (en plus du problème d’aliasing).

Citation:

---

Envoyé par mith06

Je préfère comme ca:

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

#include <stdio.h> #include <stdlib.h>   typedef struct { int a; int b; } premier;   typedef struct { premier p; char c; } second;   int main( void ) { second s; s.p.a = 10; s.p.b = 40; s.c = 2; premier * p = &s.p; printf( "a=%d, b=%d\n", p->a, p->b ); exit( 0 ); }

---

---

En plus d‘une meilleure maintenabilité, ça devrait résoudre le problème observé par dinobogan.

@dinobogan : tu peux tester le code de mith06 avec xlC pour voir si tu as toujours un résultat faux ?

Bonjour,

Personnellement je pense que cet article sur la POO en C n'est pas celui qu'il faut rédiger/lire, si le but est d'introduire les programmeurs à la POO.

On ne peut pas introduire un paradigme en partant du paradigme en question, où la scission/transition dans ce cas?

Le C n'est pas fait pour de l'objet, c'est un langage impératif et c'est comme cela que ça marche.

En revanche, une meilleure façon de faire passer les programmeurs du C au C++ est une introduction et un apprentissage du C modulaire, qui est d'ailleurs largement adopté dans le développement logiciel en C, le code du noyeau linux par exemple.

Le fond de l'article n'est pas mal, mais je le reprendrais bien en un cours sur le C modulaire, qui ferait rester le lecteur dans le C et le paradigme associé, en lui montrant une meilleure approche de la POO/C++.

Je sais que mon post ne répond pas à la question posé, mais je ne n'ai pas vu où laisser un commentaire sur la page du cours en question.

Bien cordialement

Citation:

---

Envoyé par grim7reaper

Par curiosité, ça affiche quoi ?

---

Ca affiche : a=804396748, b=804396756
Ces deux valeurs ne changent pas, même après avoir changer les affectations '10' et '40'.

Citation:

---

@dinobogan : tu peux tester le code de mith06 avec xlC pour voir si tu as toujours un résultat faux ?

---

Ce code fonctionnera sans problème. Mais je teste quand même...
Après test, ça fonctionne sans problème. Et heureusement, sinon on ne pourrait plus utiliser les structures :aie:

dinobogan,

Code:

---

premier * p = (premier *)((void*)& s);

---

A quoi sert le premier cast ici ? (void *)

PS: La norme C garantit que l'adresse d'une structure est l'adresse de son premier élément, donc p->a devrait valoir 10.

Citation:

---

Envoyé par enclair

dinobogan,

Code:

---

premier * p = (premier *)((void*)& s);

---

A quoi sert le premier cast ici ? (void *)

---

A priori, à rien...

Citation:

---

Envoyé par enclair

dinobogan,

Code:

---

premier * p = (premier *)((void*)& s);

---

A quoi sert le premier cast ici ? (void *)

---

Sans le "void*", le compilateur sort les informations de compilations suivantes :
(I) Pointer type conversion found.
(I) Pointer types "struct {...}*" and "struct {...}*" are not compatible.

Le compilateur xLC sur IBM AIX est souvent casse-pied lorsqu'on utilise une optimisation de compilation supérieure ou égale à -O3 et l'option -qsimd=auto.
Voici deux codes qui ne donnent pas le même résultat en compilant avec ces deux options :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

#include <stdio.h> #include <stdlib.h>   typedef struct { int a; int b; } premier; typedef struct { int a; int b; char c; } second;   int main( void ) { second s = { 0 }; s.a = 10; s.b = 40; s.c = 2; premier * p = (premier*)((void*)(& s)); printf( "par pointeur : a=%d, b=%d\n", p->a, p->b );   exit( 0 ); }

---

résultat :

Citation:

---

par pointeur : a=10, b=40

---

Donc OK, tout va bien.

Maintenant, supprimons l'initialisation de la structure :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

#include <stdio.h> #include <stdlib.h>   typedef struct { int a; int b; } premier; typedef struct { int a; int b; char c; } second;   int main( void ) { second s; s.a = 10; s.b = 40; s.c = 2; premier * p = (premier*)((void*)(& s)); printf( "par pointeur : a=%d, b=%d\n", p->a, p->b );   exit( 0 ); }

---

résultat :

Citation:

---

par pointeur : a=804396732, b=804396740

---

Et là c'est le drame...

Mais puisque ces options de compilations permettent de diminuer de beaucoup le temps d'exécution de mes programmes, je compile avec ces options mais je suis devenu très pointilleux sur l'usage des structures et de leurs membres.
Si quelqu'un a une explication sur ce comportement, je suis preneur car la doc officielle IBM ne dit quasiment rien sur les effets concrets des options de compilations pour l'optimisation du code. Je n'ai trouvé aucun exemple avec explication décrivant ce genre de phénomène.

La norme prévoit que toute variable lue sans avoir été initialisée est un "undefined behaviour" (voire un "undetermined behaviour"...) c'est à dire que tu ne peux pas t'y fier, et que le compilateur est libre de son choix.

Du coup, c'est logique que si tu supprimes les initialisations, tu ne saches pas ce que tu lis.

Citation:

---

Envoyé par leternel

La norme prévoit que toute variable lue sans avoir été initialisée est un "undefined behaviour" (voire un "undetermined behaviour"...) c'est à dire que tu ne peux pas t'y fier, et que le compilateur est libre de son choix.

---

Oui, on est bien d'accord. Seulement mais variables ont été initialisées, certes pas lors de la déclaration, mais juste après, membre par membre.
Du temps ou j'utilisais gcc, je n'avais jamais eu ce genre de mésaventure :roll:

En ouvrant les yeux, c'est mieux. :aie:

En effet, c'est quelque peu étrange.
D'un autre côté, une paire de cast, ca s'appelle violer le système de type.
Que, dans une telle situation, ton compilateur t'envoie bouler me semble pour le moins ... légitime.

Je suis prêt à parier que c'est un problème d'alignement des pointeurs et des pointés.

@dinobogan : merci pour le test. En effet, si le second code (celui de mith06) donnait aussi un résultat erronné cela serait très problématique.

Citation:

---

Envoyé par dinobogan

Si quelqu'un a une explication sur ce comportement, je suis preneur car la doc officielle IBM ne dit quasiment rien sur les effets concrets des options de compilations pour l'optimisation du code.

---

Mécanique interne du compilateur, et c’est en effet rarement documenté (voir impossible à documenter).
L’initialisation des membres à 0 de la structure doit influer sur les analyses de flots et/ou sur les optimisations possibles par le compilateurs.
Clairement, les deux codes sont « faux » car il y a la ligne :

Code:

---

premier * p = (premier*)((void*)(& s));

---

Car cela viole la règle de l’aliasing (comme je l’ai dit dans un message précédent), et c’est un truc très utilisé par les compilateurs pour optimiser justement.

Un très bon article sur cette règle du strict aliasing.

Citation:

---

Envoyé par grim7reaper

Clairement, les deux codes sont « faux » car il y a la ligne :

Code:

---

premier * p = (premier*)((void*)(& s));

---

Car cela viole la règle de l’aliasing (comme je l’ai dit dans un message précédent), et c’est un truc très utilisé par les compilateurs pour optimiser justement.

---

Merci pour l'article. J'ai recompilé le programme qui donne un résultat inattendu en ajoutant l'option -qalias=noansi, et le résultat devient correct.
C'était donc bien un problème d'aliasing.

Comme déjà dit (pour repartir sur le sujet initial de la discussion), il ne faut pas utiliser ce genre de code. "L'héritage" de structure comme présenté dans le premier post est une très mauvaise pratique.

Bonjour, l utilisation "d heritage" (structure enfant debutant par la declaration d une instance de la structure mere est largement utilisee en C sans aucun probleme et est une bonne technique (cf kernel). Le probleme de valeur erronee dont vous vous faites echo semble plutot du a un probleme d alignement de structure...