Discussion :

[ghost2002]

Salut à tous ! Je recherche actuellement la meilleure méthode pour créer une bibliothèque de programmation orientée objets en C.
Je cherche depuis longtemps, et j'ai lu beaucoup de code dans beaucoup de langage. Au final, je voudrais une implémentation qui ressemble à ce que l'on peut trouver en objective-C, avec les messages, les protocoles, l'héritage unique et surtout les fonctions retain () et release () ... Tout devrait aussi être thread-safe ( En utilisant l'API pthread). Aujourd'hui, j'attends vos idées, sachant que je veux pouvoir accéder aux objets de cette façon: "obj-> vptr-> write (obj, stdout)".
Il serait également souhaitable de pouvoir vérifier l'intégrité des objets, et de fournir un mécanisme privé / public / protégé (Une idée intéressante est la suivante: https://c.developpez.com/cours/regles-programmation- orientee-objet-c /? page = page_2 # LII-G).
Mais mon plus gros problème est de faire l'héritage d'une manière efficace et propre (comme je développe une bibliothèque, il serait souhaitable d'avoir une classe de base (comme NSObject) qui fournit les fonctions obligatoires (retain (), release (), copy (), ...)) ... Je sais que beaucoup vont me dire "passe au C++", ou "utilise des choses existantes", mais je répondrais que je préfère le C aux autres langages, et que j'ai besoin de quelque chose de portable (donc on oublie GObject et tout le tralala), donc merci de m'aider au lieu d'essayer de me convaincre que c'est pas la bonne manière de faire.
Je remercie tout le monde par l'avance !

[foetus]

un mécanisme privé / public / protégé

Cela on peut le faire sauf pour l'héritage via 1) les pointeurs opaques (avec 1 redirection en plus) 2) en séparant dans 2-X fichiers et en faisant les bon include (les fichiers privées incluent les fichiers publics)

Mais mon plus gros problème est de faire l'héritage d'une manière efficace et propre

Impossible en C. L'héritage en C est simple : on redéfinie les classes filles avec les données membres de la classe mère dans le même ordre et on ajoute à la fin.
Et ensuite, c'est les pointeurs et/ ou le slicing qui prennent le relais

[ghost2002]

Salut et merci de ta réponse ! Les pointeurs opaques ne sont pas une solution, étant donner que la structure représentant l'objet contient la table d’accès aux fonctions. Et si il est pas possible de faire de l’héritage, n'y a t'il pas au moins moyen de faire un objet de base, comme dit précedemment, spécialement conçu pour être hérite et fournir les fonctions importantes ? Les devellopeurs de GObject ou COS devait bien avoir des idées... J'ai essayer de lire le code, mais je le trouve extrêmement complexe...

PS: c'est quoi le slicing ?

[Bousk]

Tu peux toujours tenter un héritage à base de composition mais ça n'a pas la puissance d'un héritage réel que d'autres langages fournissent.
Sinon tu prends l'approche Python (l'implémentation, pas le langage) avec des structures bien foutues pour gérer ça et des cast à tout va. Mais c'est vite difficile à lire.

Mais en l'état, ton projet est plus proche de l'utopie. Tu en demandes clairement trop, et en plus d'être thread-safe..
Autant faire du C++, là tu pourras créer ton héritage comme tu le souhaites.
Et surtout les utilisateurs pourront également créer leur surcouche héritée de ta lib.

Tu peux créer une API portable en C par-dessus une bibliothèque écrite en C++. Et c'est sûrement ce que je ferais.

[ghost2002]

Désolé, mais là va me falloir des exemples... C'est quoi "héritage à base de composition" ? A quoi ressemble l'approche python ? Et enfin, comment on fait une surcouche sur du C++ ? Je sais que ça marche dans l'autre sens avec "extern "C" {}", mais C++ vers C ?
En fait je comprend rien dans ton message

[Bktero]

Je vais peut-être passer pour un troll mais je vais le dire quand même : passe au C++.

Si ta seule raison de rester en C c'est "j'aime le C", j'ai une nouvelle pour toi : mais le C++ c'est comme le C ! Sauf que tout ce que tu souhaites faire est déjà fourni dans le langage. Tu auras une meilleure syntaxe, un support du compilateur, pas de bug, bref que du plus.

Si ta seule raison de rester en C c'est "j'aime le C", c'est une mauvaise raison. Ne pas avoir de compilateur C++ pour ta cible serait une bonne raison.

Après si tu aimes de faire mal, c'est ton choix La question est peut-être : pourquoi vouloir faire de l'objet avec un langage clairement pas fait pour ça ?

[Sve@r]

Bonjour

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

Le faire bien