Quelle est la meilleure manière de faire de la POO en C ?

**ghost2002** · 06/07/2018, 22h30

Je croyais qu'il était impossible d’implémenter le "Run Time Type Identification" (je connaissais pas l'abréviation), et encore plus la réflexion, en C ? En objective-C tu parle des sélecteurs, n'est-ce pas ?

**foetus** · 06/07/2018, 22h44

Envoyé par ghost2002

En objective-C tu parle des sélecteurs, n'est-ce pas ?

Non, les sélecteurs sont des pointeurs de fonctions/ méthodes

Je parle de (BOOL) respondsToSelector: (SEL) aSelector (<- lien Apple anglais et il y a aussi les "See Also" sur cette page)
Et cela tu ne l'as pas en C++ et cela fait partie de la réflexion, comme la RTTI en fait partie.

**Pyramidev** · 06/07/2018, 22h48

Dans une implémentation normale du C++, le RTTI se manifeste sous la forme d'un objet std::type_info stocké au début de la table virtuelle, juste avant la succession des adresses des fonctions virtuelles. On peut suivre la même stratégie en C.

**ghost2002** · 06/07/2018, 22h56

Je parle de (BOOL) respondsToSelector: (SEL) aSelector (<- lien Apple anglais et il y a aussi les "See Also" sur cette page)

c'est ce que je voulais dire (ça utilise bien les sélecteurs

). Pyramidev, aurais-tu un exemple ? Et dans le code que tu as poster, quelle stratégie te semble la meilleure ?

PS: Que pensez-vous du code que j'ai poster ?

**Pyramidev** · 07/07/2018, 01h27

Envoyé par ghost2002

Pyramidev, aurais-tu un exemple ?

J'ai la flemme de coder le RTTI en C mais, dans les grandes lignes, voici comment on pourrait faire :

Le premier membre de chaque classe de base sans parent est un pointeur vers une table virtuelle.
Le premier membre de chaque classe dérivée est un objet dont le type est une classe de base directe.
Grâce aux deux points précédents, les 32 ou 64 premiers bits de tout objet de ces classes sont l'adresse d'une table virtuelle.
Chacune des tables virtuelles dont l'adresse peut être au début d'un objet ont pour premier membre un TypeInfo. Ainsi, à partir de tout pointeur vers un objet de ces classes, on peut accéder au TypeInfo correspondant.
TypeInfo contient un pointeur de type const TypeInfoImpl*.
TypeInfoImpl est une structure qui contient des informations sur le type, dont le nom du type et la liste des classes de base directes (par exemple sous la forme d'un tableau de TypeInfo).

Envoyé par ghost2002

Et dans le code que tu as poster, quelle stratégie te semble la meilleure ?

Si j'étais obligé de coder en C, alors je pense que la stratégie que j'utiliserais le plus souvent serait la programmation orientée protocole.
Remarque : dans LoggerHandle, j'ai mis directement un pointeur de fonction, car il n'y avait qu'une seule fonction. Mais, s'il y avait eu trop de fonctions, alors j'aurais mis un pointeur vers une structure contenant les pointeurs de fonction afin que chaque LoggerHandle prenne moins de place.

La programmation orientée objet dans le style C++ serait lourde à implémenter en C. En plus, cette forme de programmation orientée objet est moins flexible que la programmation orientée protocole car on ne peut ajouter un type parent à un type déjà existant sans modifier le code existant.

Quant à la programmation générique à coup de macros, si on l'utilise trop, alors le code sera indébogable et lent à compiler.

Envoyé par ghost2002

PS: Que pensez-vous du code que j'ai poster ?

Il y a quelques erreurs de compilation (point-virgules manquants) mais, une fois que c'est corrigé, ça marche.

Attention cependant à la gestion des erreurs :

Code :

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

1
2
3
4
5
6
7
void test_set(struct Test_private *This, int i)
{
       if (This)
       {
              This->i = i;
       }
}

Si, par étourderie, This == NULL, alors le code ci-dessus repoussera l'erreur plus loin. Alors, quand cette erreur sera détectée, il sera plus difficile de remonter à l'origine de l'erreur. Une manière de traiter l'erreur serait d'écrire un message dans la sortie d'erreur puis éventuellement d'arrêter le programme.

Personnellement, en C, comme il y a des pointeurs partout, j'adopte la convention suivante : tout pointeur est par défaut jamais nul. Si un pointeur peut être nul, alors je le signale explicitement par le nommage, par exemple avec un suffixe "OrNull". Exemple :

Code :

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

Car* carOrNull = Person_GetCarOrNull(person);

Comme ça, je distingue du premier coup d’œil les pointeurs qui peuvent être nuls.

**ghost2002** · 07/07/2018, 11h31

Je crois que je comprend à peut-près ce que tu explique, mais je vois pas ce que tu peux faire de ta structure

Code :

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

TypeInfo

. Concernant mon code, je l'ai écrit à la va vite pour vous montrer, mais si il fonctionne, je n'arrive pas à faire de l'héritage correctement, ni du polymorphisme...

**ghost2002** · 09/07/2018, 20h56

Heu... Je suis toujours intéresser ! Particulièrement par l’implémentation d'un objet de base !

**Pyramidev** · 10/07/2018, 01h38

Le RTTI permet de tester à l'exécution que le type X d'un certain objet obj dérive bien d'un certain type Y. En pratique, tu peux te passer du RTTI.

En C++, le compilateur a besoin du RTTI pour implémenter le mécanisme des exceptions typées dynamiquement : pour savoir si un bloc catch(Y&) peut attraper une exception obj, il faut pouvoir tester à l'exécution si le type de obj dérive directement ou indirectement de Y. Pour comprendre cette phrase, il faut connaître au moins un langage qui utilise les exceptions pour la gestion des erreurs (ex : C++, Java, Python...).

Pour implémenter l'héritage, si tu comprends les codes de dalfab et moi, normalement, tu devrais pouvoir implémenter l'héritage simple.

Pour comprendre le code que j'ai écrit, il faut essayer de l'exécuter pas à pas dans la tête :

Code :

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

1
2
3
4
5
6
void firstDemo() {
	LoggerDeriv logger;
	LoggerDerivCtor(&logger, stdout);
	LoggerBase* loggerPtr = &logger.super;
	LoggerLog(loggerPtr, "Object oriented programming.", LoggerLevel_Debug);
}

Point à retenir : le constructeur LoggerDerivCtor détermine la table virtuelle pointée :

Code :

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

1
2
3
4
void LoggerDerivCtor(LoggerDeriv* self, FILE* file) {
	self->super.m_vtable = &loggerDerivVTable; // à se rappeler pour comprendre la suite
	self->m_file = file;
}

Ensuite, LoggerLog fait :

Code :

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

1
2
3
void LoggerLog(LoggerBase* self, const char* msg, LoggerLevel level) {
	self->m_vtable->m_log(self, msg, level);
}

Si on tient compte des informations précédentes, cet appel à LoggerLog fait :

Code :

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

loggerDerivVTable.m_log(loggerPtr, "Object oriented programming.", LoggerLevel_Debug);

Quelle fonction pointe loggerDerivVTable.m_log ? On regarde le code :

Code :

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

LoggerVTable loggerDerivVTable = { &LoggerDerivLogWithCast };

Ensuite, on lit la définition de LoggerDerivLogWithCast :

Code :

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

1
2
3
void LoggerDerivLogWithCast(LoggerBase* self, const char* msg, LoggerLevel level) {
	LoggerDerivLog((LoggerDeriv*) self, msg, level);
}

Donc, au final, l'appel à LoggerLog ci-avant fait :

Code :

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

LoggerDerivLog((LoggerDeriv*) loggerPtr, "Object oriented programming.", LoggerLevel_Debug);

Et voilà, grâce au mécanisme des tables virtuelles, LoggerLog appelle la fonction LoggerDerivLog qui correspond bien au type réel (LoggerDeriv) de l'objet logger pointé par loggerPtr.

Après avoir lu plusieurs fois, tu pourras maintenir en mémoire en même temps toutes les étapes qui transforment l'appel de LoggerLog en appel de LoggerDeriv. Alors, tu auras progressé dans la compréhension de l'implémentation de l'héritage simple (sans RTTI).

Pour aller plus loin :
Dans mon exemple simple, il n'y a besoin que d'un seul type de table virtuelle (LoggerVTable). Mais, si une classe OtherLogger qui dérive de LoggerBase possède plus de fonction virtuelles, alors il faudra créer un nouveau type (OtherLoggerVTable). Pour que ça marche, il faudra que le début de la structure OtherLoggerVTable corresponde à la structure LoggerVTable. Donc il faudra que le premier pointeur de fonction de OtherLoggerVTable corresponde à la fonction de log.

Pour aller encore plus loin, tu pourras implémenter une classe de base avec un état, comme la classe Animal de dalfab qui stocke un nom.

Encore plus loin, il y a l'héritage multiple. Mais, là, les choses se compliquent.

Ou alors, il y a la programmation orientée protocole où la vie est simple. Pour comprendre le code que j'ai écrit, c'est la même méthode qu'avec le code firstDemo ci-avant (décortiquer les étapes puis essayer de tout maintenir en mémoire en même temps) :

Code :

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

1
2
3
4
5
6
7
void secondDemo() {
	SimpleLogger logger;
	SimpleLoggerCtor(&logger, stdout);
	LoggerHandle loggerHandle;
	LoggerHandleCtorSimpleLogger(&loggerHandle, &logger);
	LoggerHandleLog(loggerHandle, "Protocol oriented programming.", LoggerLevel_Debug);
}

**ghost2002** · 10/07/2018, 12h24

Donc si j'ai bien compris la bonne idée c'est d'utiliser les protocoles ? Peut-on tirer quelque chose de mon code ? Comment je peut faire pour implémenter les fonction retain(), release(), copy(), hash(), ... de manière générique et threads-safe ? Comment faire pour vérifier la conformité d'un objet (qu'il propose bien les fonctions de base (implémenter comment ?) ou qu'il respecte bien un protocoles) ? Peut-on combiner protocoles et héritage ? Cela présente t'il un intérêt ? Et l'héritage multiple est t'il réellement quelque chose d’utile ? Et si oui comment l’implémenter ? Ou puis-je trouver des exemple de RTTI en C ? Comment python implémente les objets (En lisant les sources j'ai cru comprendre que tous les objets hérite de PyObject, qui doit être le premier membre pour être caster, mais ça me paraît pas très propre...) ? Est-ce une bonne solution ?

Désolé, mais c'est un peut tout ce qui se bouscule dans ma cervelle actuellement

**ghost2002** · 12/07/2018, 18h39

Pitiéééééééééééééééééé ! J'ai relu ton code vingt fois, et j'ai compris (eureka !). Mais je vois pas comment utiliser ces méthodes pour optimiser la programmation de ceux qui utiliseront ma lib ! Et encore moins comment obtenir le hash d'un objet ou gérer sa mémoire via retain() et release() (enfin si, je sais faire, mais pas threads-safe)...

**Pyramidev** · 12/07/2018, 20h29

Envoyé par ghost2002

gérer sa mémoire via retain() et release() (enfin si, je sais faire, mais pas threads-safe)...

Pour rendre cela thread-safe, une méthode simple serait que chaque objet contienne un mutex. Au début de retain et release, on bloque le mutex. À la fin, on le débloque.

Mais pourquoi veux-tu gérer de la mémoire en C par du comptage de références ? Cela complexifie le code et réduit les performances, donc il faut une bonne raison.

En C, la majorité du temps, c'est celui qui alloue une ressource qui la désalloue et il n'y a pas besoin de passer par du polymorphisme pour désallouer la ressource. Là où plus personne n'a besoin d'une certaine ressource, on appelle directement la bonne fonction de désallocation et c'est bon :

Code :

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

1
2
3
4
5
6
Resource myResource; // no polymorphic
errorCode = ResourceCtor(&myResource, other parameters...); // allocation
if(errorCode == 0) {
	... // code which uses myResource
	ResourceDtor(&myResource); // deallocation
}

Dans des cas plus rares, si on simule le patron de conception Fabrique, alors on a besoin du polymorphisme pour gérer la destruction, mais pas forcément du comptage de références :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
// Protocol-oriented programming
 
typedef struct DestructibleLoggerHandle {
	void* m_obj;
	void(*m_log)(void* obj, const char* msg, LoggerLevel level);
	void(*m_dtor)(void* obj);
} DestructibleLoggerHandle;
 
void DestructibleLoggerHandleLog(DestructibleLoggerHandle self, const char* msg, LoggerLevel level) {
	self.m_log(self.m_obj, msg, level);
}
 
void DestructibleLoggerHandleDelete(DestructibleLoggerHandle self) {
	self.m_dtor(self.m_obj);
	free(self.m_obj);
}

Code :

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

1
2
3
4
5
6
DestructibleLoggerHandle owningLoggerHandle; // polymorphic
errorCode = CreateDestructibleLoggerByName(&owningLoggerHandle, loggerName); // allocation
if(errorCode == 0) {
	... // code which uses owningLoggerHandle
	DestructibleLoggerHandleDelete(owningLoggerHandle); // polymorphic deallocation
}

**ghost2002** · 12/07/2018, 21h01

Je sais qu'on peut utiliser les mutex, mais tu es d'accord qu'avant de libérer la mémoire allouer à l'objet, le destructeur détruit le mutex ? Il se passe quoi si un thread accède à l'objet à ce moment précis, celui ou le mutex est détruit, mais l'objet pas encore NULL ? Et quand au pourquoi, je pense pas que ce soit une mauvaise de rester dans la logique objective-C... Même si pour l'instant j'ai pas grand chose de concret...

**Pyramidev** · 12/07/2018, 21h40

Effectivement, si l'objet contient le mutex et si release décide qu'il faut détruire l'objet car le compteur de références tombe à zéro, alors il faut d'abord libérer le mutex avant de détruire l'objet. Donc, dans ce cas, la libération du mutex ne se fait pas complètement à la fin de l'appel de release.

Mais, sauf erreur de programmation, il n'y a pas de risque qu'un autre thread accède à l'objet entre le moment où on libère le mutex et celui où on détruit l'objet. En effet, on ne décide de le détruire que quand le compteur de références est à zéro. Or, si un autre thread veut accéder à l'objet, alors le compteur de références ne devrait pas être à zéro.

**ghost2002** · 13/07/2018, 14h32

C'est pas une erreur de programmation que deux threads nouvellement créés tentent d'accéder à une variable globale qui n'est plus utiliser par leurs "collèges"... Cela signifie compteur égal à zéro et objet pas forcément égale à NULL... Non ?

**foetus** · 13/07/2018, 17h07

Envoyé par ghost2002

C'est pas une erreur de programmation que deux threads nouvellement créés tentent d'accéder à une variable globale qui n'est plus utiliser par leurs "collèges"

C'est pour cela que ce que tu veux faire en langage C c'est tout sauf trivial/ simple/ rapide à coder

Pour moi le problème c'est de mettre un appel à delete dans le release (appel lorsque le compteur est à zéro)
Il faudrait voir comment, par exemple, l'interface IUnknown de COM a été codée.

Mais pour moi, il faut commencer à faire un ramasse-miettes (RM) en séparant d'une part une interface MyObjet retain - release (une espèce de table de pointeurs) et de l'autre l'objet lui même avec un accès protégé/ privé (seul le RM peut le créer, le détruire (c'est ce RM qui vérifie le compteur de ton objet) et transmettre son interface MyObjet si ton objet y adhére).

Le problème du langage C c'est que tu n'as pas de collections, la gestion des threads est bas niveau et que niveau accès (mémoire/ objet/ ...) c'est par défaut "open bar".
Tu parles de variables globales

: même si tu peux y arriver comme cela, je pense que dès le départ il ne faut surtout pas y penser.

**ghost2002** · 13/07/2018, 17h33

Je t'arrête ! Je parle de variables globales uniquement pour illustrer mon propos, il n'était pas question d’implémentation ! Je connait pas du tout COM (C'est une technologie Microsoft, non ?)... Pourrais-tu m'en dire plus sur ce que c'est et surtout sur l'implémentation dont tu parles ? Et aurais-tu un exemple de ce que tu proposes, d'autant que je pense que c'est précisément ce que je cherche ? Et j'ai bien compris que c'est hardcore, sinon je serais pas en train de vous embêtez

!

**Sve@r** · 13/07/2018, 18h15