héritage en C

Version imprimable

20/10/2009, 13h19
ilyes_dev

héritage en C

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.
20/10/2009, 14h28
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
20/10/2009, 22h38
nicolas.sitbon

Citation:

Envoyé par 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

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.
21/10/2009, 02h08
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.
21/10/2009, 07h07
Chatanga

Citation:

Envoyé par JulienDuSud

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++ :D
21/10/2009, 10h15
Mac LAK

Citation:

Envoyé par 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.

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.
21/10/2009, 10h21
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...
21/10/2009, 10h35
Mac LAK

Citation:

Envoyé par JulienDuSud

mais je suis plus sûr de ce que dit la norme et de ce qu'elle ne dit pas sur l'alignement...

En l'occurrence, sur ce coup, tu peux quasiment t'asseoir sur la norme : ce genre de système est rarement utilisé pour un truc devant être 100% portable, on "cible" plutôt quelques compilateurs et plate-formes données. Donc, ça se teste sur la plate-forme et tu vois si ça marche ou pas.

En effet, c'est surtout utilisé pour des choses d'assez haut niveau, où la concurrence est plutôt rude (C++ pour commencer, Delphi, C#, Java, ...). Donc, ça se résume souvent à cibler le plus courant : en compilateurs, c'est souvent CC / GCC / Visual, et en OS, le triplet Windows/Linux/MacOS.

Or, si tu veux écrire du C++ en C, tu pars quand même avec un très gros handicap, qui rendrait sûrement le portage d'un compilateur C++ bien plus rentable que de vouloir le faire en C envers et contre tout.

Côté raisons d'une telle démarche, tu peux en avoir plusieurs : volonté d'éliminer la STL et/ou les templates, compilateur C++ déficient sur une plate-forme, volonté d'obtenir une vitesse d'exécution plus élevée qu'en C++, volonté d'interface avec d'autres langages sans devoir se fader l'ABI C++, etc.
21/10/2009, 10h56
Jean-Marc.Bourguet
Ma reference favorite sur le sujet: http://ldeniau.web.cern.ch/ldeniau/html/oopc.html

Citation:

Envoyé par nicolas.sitbon

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:

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.
21/10/2009, 11h00
Médinoc
C'est pourquoi en cas d'héritage, mon réflexe est plutôt ceci:
Code:

1 2 3 4 5 6 7 8 9 struct S1 { int i; short s; }; struct S2 { struct S1 base0; short s2; };
21/10/2009, 11h04
nicolas.sitbon

Citation:

Envoyé par Jean-Marc.Bourguet

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

Je me méfie de Laurent Deniau, le peu de code que j'ai relu de lui comportait deux gros comportement indéterminé, dans son framework sur la gestion des exception, du coup, tant que personne n'aura fait une relecture fiable de son code, je ne l'utiliserais pas.
Cordialement.
21/10/2009, 11h05
Jean-Marc.Bourguet

Citation:

Envoyé par 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...

Il y a peut de contraintes sur l'alignement, mais la regle sur les premiers membres des structs dans des unions fait que de ne pas etre consistant poserait des problemes d'implementation.

Beaucoup plus genant est la possibilite d'alias. Chaque fois que j'essaie de creuser ce qui est garanti, ma consommation d'aspirines augmente. Mon impression actuelle est que la norme est inconsistante et que qui a l'air d'etre autorise par un raisonnement peut etre interdit par un autre. Et ca ne cause des problemes que quand un optimiseur decide de profiter d'une latitude est interessant...
21/10/2009, 11h05
nicolas.sitbon
Citation:
Envoyé par Médinoc

C'est pourquoi en cas d'héritage, mon réflexe est plutôt ceci:

Code:

1 2 3 4 5 6 7 8 9 struct S1 { int i; short s; }; struct S2 { S1 base0; short s2; };
C'est ma méthode aussi, et celle ci et clairement défini par la norme (voir la référence que j'ai donné au dessus).
Cordialement.
22/10/2009, 12h20
souviron34

Citation:

Envoyé par nicolas.sitbon

C'est ma méthode aussi, et celle ci et clairement défini par la norme (voir la référence que j'ai donné au dessus).
Cordialement.

absolument, ce qui est parfaitement logique avec la notion même d'héritage..

Si on hérite , c'est qu'on comprend la structure précédente, plus des différences...

Maintenant, le coup de vouloir refaire du C++ à partir de C me semble étrange, et procéder plus d'une masturbation intellectuelle que d'autre chose..

Car, avec l'héritage tel que mentionné, les TAD, et de la Conception Orientée Objet, C est tout à fait capable de manipuler des objets... De manière standard, stricte, et sans faire appel à des notions qui lui sont étrangères..

J'ai dans le fond l'impression que cela provient de gens ayant profondément peu assimilé la différence entre ce qu'est la Conception Objet par rapport à un Langage Objet..

Et qu'on peut faire des programmes très beaux, simples et faciles à maintenir, OO en C sans se référer à l'arsenal de paradigmes et constructions des LOO.
22/10/2009, 12h31
Médinoc

Si j'ai bien compris, l'héritage et la virtualité font la différence entre ce que les anglophones appellent object-based et object-oriented.
22/10/2009, 12h44
souviron34

je ne suis pas assez au courant des notions (à part de m'être fait "blaster" sur le polymorphisme et l'héritage dans un autre débat).

Mais le fond c'est que effectivement il y a beaucoup (que ?) de la confusion entre "Object-Oriented" et "Object-Language programmed".

(du style que faire MaMèthode ( MonObjet ) est stupide par rapport à faire MonObjet.MaMéthode...)
22/10/2009, 13h07
Jean-Marc.Bourguet

Citation:

Envoyé par Médinoc

Si j'ai bien compris, l'héritage et la virtualité font la différence entre ce que les anglophones appellent object-based et object-oriented.

Je ne suis pas sur qu'il y ait une definition universellement admise de l'un ou de l'autre. A mon avis, si on veut faire des nuances, il vaut mieux les definir.

Et oriente objet applique aux langages designe toujours au minimum un langage disposant d'un dispatch dynamique (ou ca varie, c'est dans les conditions supplementaires, et l'heritage n'en fait pas partie pour tout le monde), pour object based, j'ai vu deux types definitions pas du tout compatibles:
- une forme "incomplete" de oriente objet (p.e. absence de dispatch dynamique comme en Oberon), parfois dans une intention de nomenclature precise (et la il vaut mieux voir la definition utilisee), parfois dans une intention pejorative (ton langage n'est pas un vrai langage oriente objet, il est object based...)
- une sorte de langage oriente objet (s'opposant alors a "class based") sans qu'il y ait une intention pejorative (p.e. JavaScript)