Programmation orientée objets en C ANSI

Le Python wrote:

Bonjour,

Je suis recherche de documentation et de retour d'expérience
concernant la programmation orientée objet en C ANSI. Je suis en train
d'étudier l'approche utilisée par la bibliothèque GObjet du projet
Glib

Tres tres lourd et incomplet! Mieux vaut oublier.

et l'excellente documentation proposée par Laurent Deniau
(http://ldeniau.home.cern.ch/ldeniau/html/oopc/oopc.html).

C'est un expose didactique qui peut etre utilise pour de tout petit
projet. rien de plus.

Je serais
intéressé à découvrir d'autres approches. Quelqu'un as-t'il lu
l'ouvrage écrit par Alain Gourdin concernant la programmation par
objets en langage C publié chez Eyrolles?

Si c'est le livre blanc avec une bande verte (de memoire, je me souviens
plus de l'auteur) ou les messages sont des defines d'ID unique, et les
implementation une cascade de case dans un switch, il vaut mieux oublier
cette approche (et le livre)!

Comme autres publications sur le sujet, tu as ooc (en minuscule):

http://www.planetpdf.com/codecuts/pdfs/ooc.pdf

qui est bien, et Dynace:

http://algorithms.us/dynace-index.html

Ce dernier est probablement ce qu'il y a de plus acheve sur le sujet
mais tout comme ooc, il necessite un solide preprocesseur, on se
retrouve donc dans la situation d'Objective-C. Il ne supporte pas les
multimethodes ni la delegation, et son message dispatch est relativement
lent meme avec l'option assembleur. Et je ne partage les opinions de
l'auteur (voir "Dynace vs C++" et "Reasons To Use Dynace") mais ca c'est
personnel.

Je vous remercie d'avance pour vos précieux commentaires.

Depuis oopc, j'ai developpe trois framework de programmation OO en C.
Pour faire court:

- OOC-1.0 (Object Oriented C) tres inspire de C++ et de la STL (beaucoup
d'inline, et de 'template'), jamais rendu publique (qques personnes dans
ce groupe on eu un tarball du code en prive).

- OOC-2.0 tres inspire de Java parce que les interfaces (Procotol dans
OOC) offrait une dynamique que C++ n'offre pas, sauf usage abusif de
l'heritage multiple (voir le livre de John Lakos), ce qui n'est pas une
solution. Tres avance (beaucoup plus que OOC-1.0), il contient beaucoup
de concepts et de fonctionnalites (Unitest, reflection, closure, etc).
Voir le thread "conferences et C (OOC)" sur ce meme newsgroup en Dec
2005. Jamais rendu le code publique (idem OOC-1.0 pour qques
distributions privees), il est en phase de nettoyage de code depuis un
an ;-( En fait, la derniere fonctionnalite que je voulais ajouter (et
qui lui a ete fatale), c'etait les multi-methodes. Et en cherchant
comment faire et en commencant a ecrire sa doc, j'ai constate que mon
objectif de simplicite m'avait echappe avec le temps. OOC etait devenu
plus "puissant" que Java, notament grace a son systeme de "vraies"
metaclasses mais aussi plus difficile a comprendre en profondeur (en
surface, c'etait relativement simple). Et l'initialisation des classes
en multithread etait un vrai casse tete chinois.

- COS (C Object System), le dernier nee de mes elucubrations tres
inspire de Objective-C et CLOS, mais plus efficace ;-) Par rapport a
OOC, il demande un compilateur C99 (moderement conforme). Pour une fois,
mes objectifs semble atteinds: simplicite, generalite, flexibilite,
efficacite, portabilite. J'ai reduit les concepts au maximum et opte
pour le maximum de flexibilite: dynamique typing, dynamique binding
(message), dynamique linking (demande 2 phases de link). Avec ca, les
interfaces et les protocols ne sont plus utiles, les classes et les
implementations sont ouvertes, les types sont fermes (ADT partout), les
hierarchies presques 'plates' et 80% des design pattern du GoF inutiles.
A partir de ca, on accede tres simplement aux multi-methodes, aux HOM
(high order message), a la delegation de message, la delegation de type,
aux classes cluster, etc... J'ai aussi conserve les exceptions et les
fermetures parce que c'est bien pratique. Je ne sais pas quand je le
rendrais publique (ni sous quelle licence, GPL ou Boost?) mais j'ai une
presentation prevue mi decembre sur le sujet. Les choses devraient donc
se stabiliser d'ici la.

a+, ld.

Merci pour votre réponse très complète. J'ai déjà eu l'occasion de
lire l'ouvrage au sujet de ooc, mais l'usage abusif de pointeurs
générique et l'usage de awk (si mes souvenirs sont bons) ne m'ont pas
convaincu d'étudient cette approche plus en avant. Je ne connaissais
pas Dynace.

Si je comprends bien, il n'y a aucune chance de voir OOC-1.0 ni OOC-2.0
en release public. C'est dommage l'étude de ces systèmes m'aurait
intéressée. J'ai déjà entenu parler de votre framework COS ici ou
là sur comp.lang.c. Je me réjouis qu'il soit rendu public.
Prévoyez-vous de publier sur le sujet? Le point d'entrée pour
éventuelle release de COS est-il également votre site web au CERN?

En attendant, je vais continuer à expérimenter sur la base de oopc.
Mais peut-être pourriez-vous m'éclairer sur un point: en quoi gobject
est-il à oublier? Quelles ses points les plus faibles à votre avis?
Quelles sont les limitations de oopc? Qu'est-ce qui limite son
utilisation à des petits projets? (J'abuse, mais je suis curieux
d'explorer les limitations de ces techniques)

Encore merci pour tout et meilleures salutations

Thierry

Thierry Chappuis wrote:

Merci pour votre réponse très complète. J'ai déjà eu l'occasion de
lire l'ouvrage au sujet de ooc, mais l'usage abusif de pointeurs
générique et l'usage de awk (si mes souvenirs sont bons) ne m'ont pas
convaincu d'étudient cette approche plus en avant.

Idem ;-)

Je ne connaissais
pas Dynace.

Il a le merite d'exister.

Si je comprends bien, il n'y a aucune chance de voir OOC-1.0 ni OOC-2.0
en release public. C'est dommage l'étude de ces systèmes m'aurait
intéressée.

Je peux mettre sur le web un tarball du code de l'un comme de l'autre
d'ici la fin de la semaine, ou les envoyer par email. Peut-etre qu'un
interet externe me forcera a finir le nettoyage de OOC-2.0 ;-) Il y
manque encore les classes generiques (a-la Java) qui ne sont pas tres
difficile a faire mais demande un changement par un connaisseur de la
generation du code des classes. J'ai abandonne les multi-methodes avec OOC.

J'ai déjà entenu parler de votre framework COS ici ou
là sur comp.lang.c. Je me réjouis qu'il soit rendu public.
Prévoyez-vous de publier sur le sujet?

Probablement. Mais autant OOC etait 'complique' et pouvait avoir un
interet 'academique', notament sur son systeme de metaclasses, autant
COS est tres simple et je ne suis pas sur qu'un papier soit accepte sur
qqchose d'aussi simple.

Le point d'entrée pour
éventuelle release de COS est-il également votre site web au CERN?

Non, c'est encore trop tot. Le probleme, c'est que je fais ca pendant
mon temps libre, souvent le soir ou le week-end, ce qui est difficile a
combiner avec la vie de famille. Il m'est donc difficile de prevoir
quand je vais avancer significativement. Le temps integrer de
developpement sur COS depuis qu'il existe est probablement inferieur a
un mois, mais reparti sur plus d'un an. Sur OOC-2.0 il doit approcher
les 10-12 mois.

En attendant, je vais continuer à expérimenter sur la base de oopc.
Mais peut-être pourriez-vous m'éclairer sur un point: en quoi gobject
est-il à oublier? Quelles ses points les plus faibles à votre avis?

Si je me base sur la documentation, son utilisation est tres lourde.
Beaucoup de chose ne sont pas verifiees a la compilation et beaucoup de
chose sont laisses a la charge de l'utilisateur (e.g. type info) alors
que la flexibilite est reduite. Rien que la lecture de:

http://developer.gnome.org/doc/API/2.0/gobject/chapter-gobject.html

et la definition de MamanBar sont une horreur. Sans compter la profusion
des cast qui empeche le compilateur de faire son boulot. Autant ecrire
un manuel sur OOP en C et un standard de codage que de fournir une lib
comme ca.

Quelles sont les limitations de oopc? Qu'est-ce qui limite son
utilisation à des petits projets? (J'abuse, mais je suis curieux
d'explorer les limitations de ces techniques)

En partie les memes que celle qui limite gobject. oopc genere un peu
plus de code implementation, mais la philosophie est la meme
(l'implementation en revanche est tres differente!), il requiere aussi
de la bonne volonte cote utilisateur. Par exemple (section
polymorphisme) la construction:

print_person(super(mng,employee.m.person));

est franchement lourde, meme si ce n'est pas le genre de chose omni
present dans le code. On devrait avoir:

print_person(mng);

OOC-2.0 resout notament ce probleme a grand renfort de macros et ca devient:

call(mng, print);

et COS est encore plus simple:

print(mng);

A moi de poser une question ;-) J'ai vu aussi ton post sur c.l.c qui est
un peu different que celui poste ici. Quelle sont tes motivations pour
faire de la OOP en C?

a+, ld.

Encore merci pour ta réponse

Je peux mettre sur le web un tarball du code de l'un comme de l'autre
d'ici la fin de la semaine, ou les envoyer par email. Peut-etre qu'un
interet externe me forcera a finir le nettoyage de OOC-2.0 ;-) Il y
manque encore les classes generiques (a-la Java) qui ne sont pas tres
difficile a faire mais demande un changement par un connaisseur de la
generation du code des classes. J'ai abandonne les multi-methodes avec OO C.

Cela m'intéresse beaucoup et si la possibilité existe, je suis
preneur.

OOC-2.0 resout notament ce probleme a grand renfort de macros et ca devie nt:

call(mng, print);

et COS est encore plus simple:

print(mng);

A moi de poser une question ;-) J'ai vu aussi ton post sur c.l.c qui est
un peu different que celui poste ici. Quelle sont tes motivations pour
faire de la OOP en C?

J'ai commencé à programmer avec C++, puis Python/Numpy/Scipy dans le
cadre de mon doctorat à l'Ecole Polytechnique Fédéale de Lausanne
(modélisation de réacteurs biologiques et simulations
d'écoulements). Je ne suis pas programmeur de formation, mais utilise
Python et C++ intensivement pour faire de la simulation numérique.

Il y a deux ans, je me suis mis au langage C à côté du travail par
curiosité. La simplicité de sa syntaxe m'a tout de suite plu. J'ai
essayé d'expérienter avec ce langage et d'implémenter les concepts
qui m'étaient familiés en C++ et en Python. J'ai été habitué dès
le début à organiser mon code selon un modèle objet, et essayer
d'implémenter un modèle objet cohérant en C me permet d'avancer dans
ma compréhension. Des tutoriaux sur le site http://www.developpez.com
m'ont mis sur la voie, mais ces modèles sont très limités dans leur
implémentation des concepts d'héritage et de polymorphisme et ne
supportent pas l'héritage multiple. J'ai alors commencé à étudier
(par pur intérêt intellectuel) ce que pouvaient offrir des frameworks
tels que gobjet et oopc (et aussi ooc), et j'ai débuté une réflexion
sur la manière dont je pourrait les améliorer.

Mon utilsation du C, comme du C++, se limite jusqu'ici au calcul
numérique. Je ne suis pas un professionnel de l'informatique, mais un
amateur qui essaie d'expérimenter le plus possible avec le langage C.
Voilà, mes motivations ne sont rien de plus que de la curiosité.


Meilleures salutations

Thierry

a+, ld.

Laurent Deniau <laurent.deniau@cern.ch> writes:

Je peux mettre sur le web un tarball du code de l'un comme de l'autre
d'ici la fin de la semaine, ou les envoyer par email.

Si tu les mets sur un site public, j'irai vraissemblablement les voir. Si
tu envoies en mail, j'apprecierais d'etre en copie. Mais je fais rien
specialement pour moi; j'ai un projet perso en perspective pour lequel ce
se serait peut-etre utile, mais si je m'y lance, je te contacterai.

A+

--
Jean-Marc

Thierry Chappuis wrote:

Encore merci pour ta réponse

Je peux mettre sur le web un tarball du code de l'un comme de l'autre
d'ici la fin de la semaine, ou les envoyer par email. Peut-etre qu'un
interet externe me forcera a finir le nettoyage de OOC-2.0 ;-) Il y
manque encore les classes generiques (a-la Java) qui ne sont pas tres
difficile a faire mais demande un changement par un connaisseur de la
generation du code des classes. J'ai abandonne les multi-methodes avec OOC.

Cela m'intéresse beaucoup et si la possibilité existe, je suis
preneur.

Je vais voir ce que je peux faire d'ici ce week-end. Essayer de faire au
moins en sorte que les modules ooc-core et ooc-std compilent et voir si
les testsuites fonctionnent toujours.

OOC-2.0 resout notament ce probleme a grand renfort de macros et ca devient:

call(mng, print);

et COS est encore plus simple:

print(mng);

A moi de poser une question ;-) J'ai vu aussi ton post sur c.l.c qui est
un peu different que celui poste ici. Quelle sont tes motivations pour
faire de la OOP en C?

J'ai commencé à programmer avec C++, puis Python/Numpy/Scipy dans le
cadre de mon doctorat à l'Ecole Polytechnique Fédéale de Lausanne
(modélisation de réacteurs biologiques et simulations
d'écoulements).

On est voisin donc ;-)

Je ne suis pas programmeur de formation, mais utilise
Python et C++ intensivement pour faire de la simulation numérique.

Il y a deux ans, je me suis mis au langage C à côté du travail par
curiosité. La simplicité de sa syntaxe m'a tout de suite plu. J'ai

Elle n'est qu'apparente.

essayé d'expérienter avec ce langage et d'implémenter les concepts
qui m'étaient familiés en C++ et en Python. J'ai été habitué dès
le début à organiser mon code selon un modèle objet, et essayer
d'implémenter un modèle objet cohérant en C me permet d'avancer dans
ma compréhension. Des tutoriaux sur le site http://www.developpez.com
m'ont mis sur la voie, mais ces modèles sont très limités dans leur
implémentation des concepts d'héritage et de polymorphisme et ne
supportent pas l'héritage multiple.

L'heritage multiple n'est pas une necessite, il y a des alternatives
souvent moins contraignantes et surtout moins compliquees.

J'ai alors commencé à étudier
(par pur intérêt intellectuel) ce que pouvaient offrir des frameworks
tels que gobjet et oopc (et aussi ooc), et j'ai débuté une réflexion
sur la manière dont je pourrait les améliorer.

Il y a deux deux etapes. La premiere etape se ramene a la definition
d'un "standard de codage" avec eventuellement un petit runtime. Dans ce
cas, avec quelques regles simples tu peux ecrire du code proche de Java.
Mais il te faudra ecrire pas mal de chose a la main. Avec le temps, les
idiomes deviendront naturels. C'est en general par la qu'il faut
commencer pour savoir ou tu veux aller. Par exemple, j'ai un debut de
papier sur le modele objet de C++, avec les objets et les classes (et
les tables virtuelles et les type_info) entierement ecrit en C. C'etait
juste pour montrer certains concepts (methode virtuelle, thunk, heritage
multiple, heritage virtuel, dynamic_cast, type covariant et
contravariant, etc...) pour la FAQ francaise du C++. Le code est fini,
mais pas la doc. C'est fou ce que ca prend du temps d'ecrire de la doc...

La deuxieme etape est de commencer a 'generer' du code pour se
simplifier la vie et laisser le compilateur faire plus de travail. Cette
etape requiere un preprocesseur et la les choses se compliquent, surtout
si on veut aller loin, la frontiere entre preprocesseur et compilateur
etant assez floue. J'ai opte pour du C pur et dur, donc le seul
preprocesseur disponible est CPP. Il faut alors connaitre les limites du
C (peut-etre le plus difficile), avoir un peu d'imagination, un bonne
comprehension des modeles existants et de leur implementations (inclus
les systemes de type si tu veux en tenir compte) et du TEMPS. Mon
probleme c'est que j'ai trop d'imagination et pas beaucoup de temps ;-).
J'ai etudier une vingtaine de languages ayant des modeles differents (ou
au moins des variantes interessantes) et lu une tonne de papiers (pas
loin d'etre vrai meme au sens propre) avant d'arriver a voir ou etait
l'essentiel. C'est peut-etre ce qui prend le plus de temps et a cause'
la lente evolution de oopc->OOC1->OOC2->COS.

Mon utilsation du C, comme du C++, se limite jusqu'ici au calcul
numérique. Je ne suis pas un professionnel de l'informatique, mais un
amateur qui essaie d'expérimenter le plus possible avec le langage C.

Idem, excepte que mon domaine d'application (les champs magnetiques) va
de l'acquisition de mesures (prog bas niveau) a la simulation de modele
(prog haut niveau). L'idee est d'utiliser les modeles pour detecter des
problemes de mesures qu'actuellement on decouvre des mois apres lors du
depouillement des donnees et de leur confrontation avec la simulation ou
avec d'autres analyses dites de plus haut niveau.

Voilà, mes motivations ne sont rien de plus que de la curiosité.

C'est un bon depart ;-)

Sans vouloir declancher une polemique, les reponses que tu as eues sur
c.l.c sont surtout le resultat d'une ignorance sur le sujet...

a+, ld.

Je vais voir ce que je peux faire d'ici ce week-end. Essayer de faire au
moins en sorte que les modules ooc-core et ooc-std compilent et voir si
les testsuites fonctionnent toujours.

Ne sacrifiez pas votre temps précieux juste pour moi. Comme l'a dit
Jean-Marc Bourget plus haut, si vous avez de toute manière prévu de
le faire, je suis très intéressé, sinon j'ai déjà beaucoup de
matière à réflexion.

On est voisin donc ;-)

Oui, enfin presque... j'habite Fribourg!

Je ne suis pas programmeur de formation, mais utilise
Python et C++ intensivement pour faire de la simulation numérique.

Il y a deux ans, je me suis mis au langage C à côté du travail par
curiosité. La simplicité de sa syntaxe m'a tout de suite plu. J'ai

Elle n'est qu'apparente.

Je m'en rend compte petit à petit

Il y a deux deux etapes. La premiere etape se ramene a la definition
d'un "standard de codage" avec eventuellement un petit runtime. Dans ce
cas, avec quelques regles simples tu peux ecrire du code proche de Java.
Mais il te faudra ecrire pas mal de chose a la main. Avec le temps, les
idiomes deviendront naturels. C'est en general par la qu'il faut
commencer pour savoir ou tu veux aller.

Oui, c'est cela qui m'intéresse dans un premier temps. Décortiquer le
modèle sous-jacent de oopc est très instructif. Avec un standard de
codage adéquat, il me semble pas trop difficile d'implémenter un
semblant d'héritage simple et de polymorphisme. Les tutoriaux que j'ai
lu sur http://www.developpez.com sont très instructifs pour cela.

Par exemple, j'ai un debut de

papier sur le modele objet de C++, avec les objets et les classes (et
les tables virtuelles et les type_info) entierement ecrit en C. C'etait
juste pour montrer certains concepts (methode virtuelle, thunk, heritage
multiple, heritage virtuel, dynamic_cast, type covariant et
contravariant, etc...) pour la FAQ francaise du C++. Le code est fini,
mais pas la doc. C'est fou ce que ca prend du temps d'ecrire de la doc...

N'hésitez pas à me contacter lorsque cet article sera rendu public,
la documentation sur le sujet manque cruellement.

La deuxieme etape est de commencer a 'generer' du code pour se
simplifier la vie et laisser le compilateur faire plus de travail. Cette
etape requiere un preprocesseur et la les choses se compliquent, surtout
si on veut aller loin, la frontiere entre preprocesseur et compilateur
etant assez floue. J'ai opte pour du C pur et dur, donc le seul
preprocesseur disponible est CPP. Il faut alors connaitre les limites du
C (peut-etre le plus difficile), avoir un peu d'imagination, un bonne
comprehension des modeles existants et de leur implementations (inclus
les systemes de type si tu veux en tenir compte) et du TEMPS. Mon
probleme c'est que j'ai trop d'imagination et pas beaucoup de temps ;-).
J'ai etudier une vingtaine de languages ayant des modeles differents (ou
au moins des variantes interessantes) et lu une tonne de papiers (pas
loin d'etre vrai meme au sens propre) avant d'arriver a voir ou etait
l'essentiel. C'est peut-etre ce qui prend le plus de temps et a cause'
la lente evolution de oopc->OOC1->OOC2->COS.

J'ai loin d'avoir votre expérience, et je commence à me confronter à
différents modèles. C'est très instructif et ça prend surtout
beaucoup de temps. Je connais essentiellement C++ et Python, mais je
commence à découvrir les langages fonctionnels tels que Haskel,
OCaml, Common Lisp/CLOS.

Mon utilsation du C, comme du C++, se limite jusqu'ici au calcul
numérique. Je ne suis pas un professionnel de l'informatique, mais un
amateur qui essaie d'expérimenter le plus possible avec le langage C.

Idem, excepte que mon domaine d'application (les champs magnetiques) va
de l'acquisition de mesures (prog bas niveau) a la simulation de modele
(prog haut niveau). L'idee est d'utiliser les modeles pour detecter des
problemes de mesures qu'actuellement on decouvre des mois apres lors du
depouillement des donnees et de leur confrontation avec la simulation ou
avec d'autres analyses dites de plus haut niveau.

Voilà, mes motivations ne sont rien de plus que de la curiosité.

C'est un bon depart ;-)

Sans vouloir declancher une polemique, les reponses que tu as eues sur
c.l.c sont surtout le resultat d'une ignorance sur le sujet...

C'est difficile de se documenter sur le sujet parce que la réponse
immédiate est: "pourquoi n'utilses-tu pas C++?" Ou encore: "tu sais,
le C n'est pas adapté à l'orienté objet, essaie plutôt C++." Je
sais que C++ existe et l'utilise relativement souvent bien que je ne me
considère pas comme un spécialiste dans ce langage que je trouve
difficile à maîtriser. L'existence de oopc, OOC-1.0, OOC-2.0, COS
semble me confirmer que vouloir se documenter sur la manière de
programmer dans un style orienté objet en C n'est pas une idée
totalement saugrenue.

Je ne poste pas souvent sur c.l.c (je suis plutôt un lecteur assidu,
bien que cela me permettrait d'améliorer mon anglais), et je trouve
habituellement les réponses pertinantes. Cela semble supposer que
l'utilsation d'approches orientées objets (à différents niveaux de
complexité) n'est pas une pratique très répendue dans la pratique
industrielle de C.

Merci pour tout et meilleures salutations

Thierry

a+, ld.

Thierry Chappuis wrote:

Je vais voir ce que je peux faire d'ici ce week-end. Essayer de faire au
moins en sorte que les modules ooc-core et ooc-std compilent et voir si
les testsuites fonctionnent toujours.

Ne sacrifiez pas votre temps précieux juste pour moi. Comme l'a dit
Jean-Marc Bourget plus haut, si vous avez de toute manière prévu de
le faire, je suis très intéressé, sinon j'ai déjà beaucoup de
matière à réflexion.

Juste pour voir, j'ai recompile le 'core' et les testsuites. A part les

'dereferencing type-punned pointer will break strict-aliasing rules'

introduit dans gcc4, tout compile et marche. J'ai changer les casts qui
generait le warning en void* pour un compilation plus propre.

Il y a deux deux etapes. La premiere etape se ramene a la definition
d'un "standard de codage" avec eventuellement un petit runtime. Dans ce
cas, avec quelques regles simples tu peux ecrire du code proche de Java.
Mais il te faudra ecrire pas mal de chose a la main. Avec le temps, les
idiomes deviendront naturels. C'est en general par la qu'il faut
commencer pour savoir ou tu veux aller.

Oui, c'est cela qui m'intéresse dans un premier temps. Décortiquer le
modèle sous-jacent de oopc est très instructif. Avec un standard de
codage adéquat, il me semble pas trop difficile d'implémenter un
semblant d'héritage simple et de polymorphisme.

Dans ce cas, je vous mettrais aussi le debut de papier sur le modele
C++, c'est l'etape d'apres de oopc pour ceux qui ont de l'huile de coude
a revendre. C'est sur ce genre de code qu'on apprecit le travail du
compilateur C++ ;-)

Les tutoriaux que j'ai
lu sur http://www.developpez.com sont très instructifs pour cela.

Des pointeurs?

Par exemple, j'ai un debut de

papier sur le modele objet de C++, avec les objets et les classes (et
les tables virtuelles et les type_info) entierement ecrit en C. C'etait
juste pour montrer certains concepts (methode virtuelle, thunk, heritage
multiple, heritage virtuel, dynamic_cast, type covariant et
contravariant, etc...) pour la FAQ francaise du C++. Le code est fini,
mais pas la doc. C'est fou ce que ca prend du temps d'ecrire de la doc...

N'hésitez pas à me contacter lorsque cet article sera rendu public,
la documentation sur le sujet manque cruellement.

cf ci-dessus.

La deuxieme etape est de commencer a 'generer' du code pour se
simplifier la vie et laisser le compilateur faire plus de travail. Cette
etape requiere un preprocesseur et la les choses se compliquent, surtout
si on veut aller loin, la frontiere entre preprocesseur et compilateur
etant assez floue. J'ai opte pour du C pur et dur, donc le seul
preprocesseur disponible est CPP. Il faut alors connaitre les limites du
C (peut-etre le plus difficile), avoir un peu d'imagination, un bonne
comprehension des modeles existants et de leur implementations (inclus
les systemes de type si tu veux en tenir compte) et du TEMPS. Mon
probleme c'est que j'ai trop d'imagination et pas beaucoup de temps ;-).
J'ai etudier une vingtaine de languages ayant des modeles differents (ou
au moins des variantes interessantes) et lu une tonne de papiers (pas
loin d'etre vrai meme au sens propre) avant d'arriver a voir ou etait
l'essentiel. C'est peut-etre ce qui prend le plus de temps et a cause'
la lente evolution de oopc->OOC1->OOC2->COS.

J'ai loin d'avoir votre expérience, et je commence à me confronter à
différents modèles. C'est très instructif et ça prend surtout
beaucoup de temps. Je connais essentiellement C++ et Python, mais je
commence à découvrir les langages fonctionnels tels que Haskel,
OCaml, Common Lisp/CLOS.

C'est un bon debut. Les languages fonctionnels a typage statique
(Haskell, SML, OCaml, Clean) apportent surtout qqchose dans le domaine
des types (inference) mais assez peu cote polymorphisme compare a C++
par exemple (meme s'ils en parle tout le temps ;-) ). CLOS est le summum
de la flexibilite, je recommande http://www.dreamsongs.com/CLOS.html et
le livre qui y est cite (meme si ca date un peu). On y trouve la base
des generiques (Dylan, COS ;-) ) et aussi un systeme d'initialisation
ultra complique. Si CLOS vous interesse, alors l'algorithme C3 aussi
(Perl6, Python, Cecil). Perso, dans COS j'ai opte pour un algo avec
ordre total, un heritage simple et une delegation tres rapide, et un
schema initialisation different plus simple et plus proche de l'idiome
super.init() de Java et Objective-C mais etendu aux multimethodes.

Regardez aussi Cecil, Slate, Dylan, Self, Beta. Tous on des modeles
differents. Dans les variantes, il y a Java et ses nombreuses
extensions, D (relativement commun), Eiffel, C# (idem D), Ada,
Objective-C. Ensuite, il y a les languages interpretes, mais la c'est un
peu different (Erlang, Lua, Ruby, Perl6, Python).

C'est difficile de se documenter sur le sujet parce que la réponse
immédiate est: "pourquoi n'utilses-tu pas C++?" Ou encore: "tu sais,
le C n'est pas adapté à l'orienté objet, essaie plutôt C++."

J'ai utilise C++ pendant 14 ans avant de revenir au C OO ;-)

Je
sais que C++ existe et l'utilise relativement souvent bien que je ne me
considère pas comme un spécialiste dans ce langage que je trouve
difficile à maîtriser. L'existence de oopc, OOC-1.0, OOC-2.0, COS
semble me confirmer que vouloir se documenter sur la manière de
programmer dans un style orienté objet en C n'est pas une idée
totalement saugrenue.

Non. Il semble que par exemple Dynace reponde a une demande (voir la
licence).

Je ne poste pas souvent sur c.l.c (je suis plutôt un lecteur assidu,
bien que cela me permettrait d'améliorer mon anglais), et je trouve
habituellement les réponses pertinantes. Cela semble supposer que
l'utilsation d'approches orientées objets (à différents niveaux de
complexité) n'est pas une pratique très répendue dans la pratique
industrielle de C.

Probable. Pour un code remarquable ou la programation OO en C est
utilisee sans tout cacher par une artillerie de macros, tu peux regarder
le code de la machine virtuelle de Java ecrite par Sun (telechargeable
gratuitement). Un delice de clarete (sans ironie). Quand meme beau de
voir que la portabilite de Java passe par la portabilite du C ;-)

a+, ld.

Dans ce cas, je vous mettrais aussi le debut de papier sur le modele
C++, c'est l'etape d'apres de oopc pour ceux qui ont de l'huile de coude
a revendre. C'est sur ce genre de code qu'on apprecit le travail du
compilateur C++ ;-)

Un grand merci d'avance

Les tutoriaux que j'ai
lu sur http://www.developpez.com sont très instructifs pour cela.

Des pointeurs?

http://c.ftp-developpez.com/downloads/c/regle.pdf
http://chgi.developpez.com/c/objet/
http://chgi.developpez.com/c/heritage/

Rien à voir ni avec ooc ni avec oopc.

C'est un bon debut. Les languages fonctionnels a typage statique
(Haskell, SML, OCaml, Clean) apportent surtout qqchose dans le domaine
des types (inference) mais assez peu cote polymorphisme compare a C++
par exemple (meme s'ils en parle tout le temps ;-) ). CLOS est le summum
de la flexibilite, je recommande http://www.dreamsongs.com/CLOS.html et
le livre qui y est cite (meme si ca date un peu). On y trouve la base
des generiques (Dylan, COS ;-) ) et aussi un systeme d'initialisation
ultra complique. Si CLOS vous interesse, alors l'algorithme C3 aussi
(Perl6, Python, Cecil). Perso, dans COS j'ai opte pour un algo avec
ordre total, un heritage simple et une delegation tres rapide, et un
schema initialisation different plus simple et plus proche de l'idiome
super.init() de Java et Objective-C mais etendu aux multimethodes.

Regardez aussi Cecil, Slate, Dylan, Self, Beta. Tous on des modeles
differents. Dans les variantes, il y a Java et ses nombreuses
extensions, D (relativement commun), Eiffel, C# (idem D), Ada,
Objective-C. Ensuite, il y a les languages interpretes, mais la c'est un
peu different (Erlang, Lua, Ruby, Perl6, Python).

Là, il y a du pain sur la planche... il y en tout cas Cecil, Slate,
Dylan, Self et Beta dont je n'ai jamais entenu ne serait-ce que parler.
Cala va m'ouvrir de nouveaux horizons et occuper mes soirées d'hiver!

Probable. Pour un code remarquable ou la programation OO en C est
utilisee sans tout cacher par une artillerie de macros, tu peux regarder
le code de la machine virtuelle de Java ecrite par Sun (telechargeable
gratuitement). Un delice de clarete (sans ironie). Quand meme beau de
voir que la portabilite de Java passe par la portabilite du C ;-)

On m'avait conseillé de voir ce qui se faisait en matière de C OO
dans le code source de xorg, mais je vais peut-être plus volontiers
regarder sous le capot de Java.

Merci pour toutes vos réponses et les pointeurs

Meilleures salutations

Thierry

a+, ld.

Thierry Chappuis wrote:

Dans ce cas, je vous mettrais aussi le debut de papier sur le modele
C++, c'est l'etape d'apres de oopc pour ceux qui ont de l'huile de coude
a revendre. C'est sur ce genre de code qu'on apprecit le travail du
compilateur C++ ;-)

Un grand merci d'avance

Les tutoriaux que j'ai

lu sur http://www.developpez.com sont très instructifs pour cela.

Des pointeurs?

http://c.ftp-developpez.com/downloads/c/regle.pdf
http://chgi.developpez.com/c/objet/
http://chgi.developpez.com/c/heritage/

Rien à voir ni avec ooc ni avec oopc.

Effectivement, mieux vaut eviter ce genre d'approches.

En C, il faut voir la OOP comme le niveau suivant les ADT, et qui
fournit aux ADT la notion de polymorphisme. Les approches qui commence
par essayer d'imite la syntaxe des languages OO sont generalement vouees
a l'echec. Le C n'est pas OO, il faut donc lui trouver sa propre syntaxe
avec les moyens dont il dispose. Si l'approche utilise une table
virtuelle, un appel de methode doit ressembler (en l'absence de macro
wrapper) a qqchose comme:

obj->cls->mth(obj[, args]); // C++ virtual member function

ou

dic->mth(obj1, obj2); // Haskell class dictionnary

Probable. Pour un code remarquable ou la programation OO en C est
utilisee sans tout cacher par une artillerie de macros, tu peux regarder
le code de la machine virtuelle de Java ecrite par Sun (telechargeable
gratuitement). Un delice de clarete (sans ironie). Quand meme beau de
voir que la portabilite de Java passe par la portabilite du C ;-)

On m'avait conseillé de voir ce qui se faisait en matière de C OO
dans le code source de xorg, mais je vais peut-être plus volontiers
regarder sous le capot de Java.

xorg est aussi un cas interessant, mais je trouve le code beaucoup moins
clair.

a+, ld.