Je suis particulièrement intéressé par les objets destinés à être utilisés à partir de C, par opposition à la mise en œuvre d'objets qui forment le noyau des langues interprétées telles que Python.
6 Réponses :
bibliothèques telles que GOBJECT .
Fondamentalement GOBJECT fournit un moyen courant de décrire les valeurs opaques (entiers, chaînes) et objets (en décrivant manuellement l'interface - comme une structure des pointeurs de fonction, corrigeant essentiellement une machine à visser en C ++) - plus d'informations sur la structure peuvent être trouvées. Dans son Référence
Vous impliqueriez souvent des vtables à main à la main comme dans "COM dans la plaine C" < / a>
EFramey - Pourriez-vous décrire la stratégie de mise en œuvre de GOBJECT dans votre réponse afin que nous puissions le comparer à certaines des autres solutions données?
Regardez Mise en œuvre de IJG . Ils n'utilisent pas seulement SETJMP / LONDJMP pour une manipulation des exceptions, ils ont des vtables et tout. C'est une bibliothèque assez écrite et assez petite pour que vous ayez un très bon exemple.
Savez-vous s'ils utilisent une mise en œuvre comme celle suggérée par Dale et Falaina? Ou quelque chose d'un peu plus dynamique?
J'ai tendance à faire quelque chose comme ceci: avec ces définitions de structure, le code implémentant FOO semble quelque chose comme ceci: p> foo_blah(foop, ...);
foo_plugh(foop, ...);
Votre utilisation du terme "objets" est un peu vague, je vais donc supposer que vous demandez comment utiliser c pour atteindre certains aspects de la programmation orientée objet (n'hésitez pas à me corriger sur cette hypothèse. )
Polymorphisme de la méthode: strong> p> La méthode polymorphisme est typiquement émulée dans C utilisant des pointeurs de fonction. Par exemple, si j'avais une structure que j'avais l'habitude de représenter une image_scaler (quelque chose qui prend une image et la redimensionne à de nouvelles dimensions), je pourrais faire quelque chose comme ceci: p> struct base{
int x;
int y;
}
struct derived{
struct base;
int z;
}
Merci Falain (j'ai suscité). Pourriez-vous indiquer une bibliothèque qui fait cela, donc moi ou quiconque pouvait examiner toute une implémentation?
Semblable à l'approche de Dale, mais un peu plus d'un pied-de-pied est la façon dont PostgreSQL représente les nœuds d'arbres, les types d'expression et l'autre en interne. Il existe par défaut nœud code> et expr code> structs, le long des lignes de typedef struct {
NodeTag n = FOO_NODE;
/* other members go here */
} FooNode;
Il y a longtemps, il y a longtemps (vers 1988) J'ai travaillé sur un compilateur C où les nœuds d'analyse étaient une union des types de noeuds individuels, avec une étiquette de type à l'extérieur de l'Union pour décider quelle branche de l'Union était valide: cela est moralement équivalent à ce que vous avez décris. Aujourd'hui, je le ferais presque certainement dans le sens de ma suggestion ci-dessus. Je trouve que l'utilisation des pointeurs de la fonction me force vraiment à définir l'API publique souhaitée - puisque l'appelant ne connaît pas le nom de la fonction, il est très difficile de toucher la fonction de la fonction pour utiliser des données internes sur la mise en œuvre.
Soupir ... S / Bit Union / Big Union / Dans ce qui précède. Désolé pour la faute de frappe.
L'approche du pointeur de fonction est définitivement supérieure - pour une chose, il vous permet d'approcher des méthodes de liaison à l'objet. J'aime tes exemples et j'ai voté.
Comme vous pouvez le constater à partir de la navigation sur toutes les réponses, il y a des bibliothèques, Pointeurs de fonction, moyens d'héritage, encapsulation, etc., tous Disponible (C ++ était à l'origine un front-end pour C).
Cependant, j'ai trouvé qu'un aspect très important du logiciel est lisibilité. Avez-vous essayé de lire le code à partir de 10 ans? Comme un résultat, j'ai tendance à prendre l'approche la plus simple lorsque vous faites des choses comme Objets en C.
Demandez ce qui suit:
Je revenons habituellement à quelque chose comme l'API de la glib qui me permet de me permettre de
Encapsulez mon code et fournit une interface très lisible. Si plus
est nécessaire, j'ajoute des pointeurs de fonction pour le polymorphisme.
Bien que j'ai toujours utilisé ce que je suppose que vous pouviez appeler un style de programmation "d'objet basé sur un objet", il est beaucoup plus facile de pour cela (et à peu près tout le reste) en C ++. Je dois demander pourquoi vous ne semblez pas vouloir l'utiliser?
@Neil: S'il n'y aurait aucune raison, il n'y aurait pas de GOBJECT. Il existe de nombreuses raisons pour C: Plateformes obsolètes, la projection, la compatibilité binaire ABI, vous l'appelez.
@Efraïm je suis bien conscient de ces raisons, mais je demandais quels sont les raisons du questionneur.
@Niel - ne pas vouloir injecter C ++ comme une dépendance devrait être une raison suffisante. De plus, il y a beaucoup de solutions intelligentes là-bas ... j'aimerais les voir documentés / comparés ici.