Discussion :

[ilyes_dev]

salut tout le monde,

J'ai lu récemment, dans un article, qu'on peut parler de la notion d'héritage en C en forçant l'adresse d'une fonction et de sa sous classe.
Est que quelqu'un a une idée sur cette notion et qui peux mieux expliquer?

merci d'avance.

[diogene]

Tu trouveras des informations dans les tutoriels de ce site.
Notamment dans Programmation orientée objets en C ? et dans la deuxième partie de ce tutoriel Héritage

[nicolas.sitbon]

Tu trouveras des informations dans les tutoriels de ce site.
Notamment dans Programmation orientée objets en C ? et dans la deuxième partie de ce tutoriel Héritage

Je suis sceptique sur cette manière de faire de l'héritage en C, quelqu'un aurait une référence dans la norme sur la légitimité de transtyper un type structure dans un autre. Autant je sais qu'il y a une relax dans le cas de structures dans une union (6.5.2.3.5), ou encore du premier membre dans une structure (6.7.2.1.13), mais pour le cas du tutoriel, j'ai un doute.
Cordialement.

[JulienDuSud]

Pareil que ci-dessus. L'article ne parle pas non plus du padding que peut engendrer (ou enlever) les nouveaux membres, et la problématique que peut engendrer un transtypage.

[Chatanga]

L'article ne parle pas non plus du padding que peut engendrer (ou enlever) les nouveaux membres, et la problématique que peut engendrer un transtypage.

C'est possible ça, qu'un ajout à la fin (et non une insertion) d'un nouveau membre dans une structure puisse changer l'alignement des membres précédents ? Si c'est le cas, je pense qu'il faudrait prévenir les gens qui bossent sur GTK, qu'ils arrêtent de perdre leur temps et passent à Qt et au C++

[Jean-Marc.Bourguet]

Ma reference favorite sur le sujet: http://ldeniau.web.cern.ch/ldeniau/html/oopc.html

Je suis sceptique sur cette manière de faire de l'héritage en C, quelqu'un aurait une référence dans la norme sur la légitimité de transtyper un type structure dans un autre. Autant je sais qu'il y a une relax dans le cas de structures dans une union (6.5.2.3.5), ou encore du premier membre dans une structure (6.7.2.1.13), mais pour le cas du tutoriel, j'ai un doute.

Tu as raison d'avoir un doute. J'ai la certitude que ce n'est pas permis.

Code :

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

1
2
3
4
5
6
7
8
9
10
 
struct S1 {
   int i;
   short s;
};
 
struct S2 {
   int i;
   short s1, s2;
};

S1 peut avoir du padding a la fin et les ecritures dans S1::s considerer qu'on peut le modifier. Ce qui est plutot genant si en fait on a un S2.

[Mac LAK]

Pareil que ci-dessus. L'article ne parle pas non plus du padding que peut engendrer (ou enlever) les nouveaux membres, et la problématique que peut engendrer un transtypage.

C'est de la programmation ORIENTÉE objet, et non pas un LANGAGE objet.

En POO, tu n'enlèves pas de membres pour commencer (=> pas de risques de "trous" dans la VMT). Et quand tu en rajoutes, c'est systématiquement à la fin, quoi qu'il arrive. En optimisant, on se retrouve avec deux tables : une pour les attributs, une pour les méthodes, et un élément présent dans une classe ancêtre reste visible dans tous les descendants.

Côté padding, c'est plutôt facile à régler : il n'y en a pas pour les pointeurs de méthode (ben oui, c'est des mots-machine, donc alignés par défaut), et pour les attributs il n'y a pas de modification des paddings "précédents" lors de l'ajout d'un nouveau champ (qui peut avoir ou pas un padding "propre").
Au pire, si ça devient ennuyeux, il est toujours possible de forcer le padding à une valeur quelconque.

Après, si tu insères des méthodes / attributs n'importe où dans la "classe", forcément, c'est chercher les ennuis... Et en C, en général, on les trouve.

[JulienDuSud]

Sur le coup j'me sens un peu con d'avoir sorti ça (en même temps il était 2h :p) Je sais plus à quoi je pensais, à la portabilité je crois, mais je suis plus sûr de ce que dit la norme et de ce qu'elle ne dit pas sur l'alignement...