Fonction générique de manipulation de structure (TAD)

Version imprimable

Bonjour,

Je travaille sur un projet personnel de bibliothèque en C orienté objet (TAD).
J'aimerais implémenter un mécanisme de comptage de référence. Pour ça, tous mes TAD doivent contenir un compteur, et une fonction doit pouvoir utiliser ce compteur de façon générique, c'est-à-dire que j'aimerais éviter de redéfinir les fonctions de manipulation de ce compteur pour chaque TAD.

J'aimerais pouvoir faire la chose suivante :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 struct MonTAD { struct gestionReferences; /* ... autres membres */ }; struct AutreTAD { struct gestionReferences; /* autres "autres membres" */ }; void Incrementer(void *tad) { struct gestionReferences * gestionnaire = (struct gestionReferences *)tad; gestionnaire->compteur++; } void Decrementer(void *tad) { struct gestionReferences * gestionnaire = (struct gestionReferences *)tad; gestionnaire->compteur--; if (gestionnaire->compteur == 0) gestionnaire->DestructeurAffecteParLeContructeurDuTAD(); }
La logique me dit que c'est possible, mais j'aimerais m'assurer qu'il n'y a pas de problèmes de décalage d'adresse entre l'adresse du TAD et l'adresse de son premier membre, ou si au pire je devrais passer par une structure de ce genre :
Code:

1 2 3 struct TADGenerique { struct gestionReferences; };
Merci,
Spootnik :)

21/12/2008, 03h25
Emmanuel Delahaye
Citation:
Envoyé par Spootnik

La logique me dit que c'est possible, mais j'aimerais m'assurer qu'il n'y a pas de problèmes de décalage d'adresse entre l'adresse du TAD et l'adresse de son premier membre, ou si au pire je devrais passer par une structure de ce genre :

Code:

1 2 3 struct TADGenerique { struct gestionReferences; };
Pour les données génériques, je recommande un void * sur les données (dynamiques, en général) de l'application. C'est le plus simple. Les données sont entièrement gérées par l'application. Le TAD n'enregistre que l'adresse et s'occupe du comportement (logique, algorithme).

http://emmanuel-delahaye.developpez.com/tad.htm

Un code structuré comme cela devrait en principe fonctionner:

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
struct gestionReferences {
    size_t compteur;
    /* eventuellement d'autres membres */
};
 
struct MonTAD {
    struct gestionReferences gestionnaire;
    /* ... autres membres */
};
 
struct AutreTAD {
    struct gestionReferences gestionnaire;
    /* autres "autres membres" */
};
 
void Incrementer(void *tad)
{
    struct gestionReferences * gestionnaire = (struct gestionReferences *)tad;
    gestionnaire->compteur++;
}

Thierry

21/12/2008, 14h53
Ceylo

Citation:

Envoyé par Emmanuel Delahaye

Pour les données génériques, je recommande un void * sur les données (dynamiques, en général) de l'application. C'est le plus simple. Les données sont entièrement gérées par l'application. Le TAD n'enregistre que l'adresse et s'occupe du comportement (logique, algorithme).

http://emmanuel-delahaye.developpez.com/tad.htm

Mon problème est surtout d'être certain que l'adresse du premier objet d'une structure est la même que l'adresse de la structure.

Citation:

Envoyé par Thierry Chappuis

Un code structuré comme cela devrait en principe fonctionner:

C'est bien le "en principe" qui me chagrine :aie:.
21/12/2008, 16h26
Emmanuel Delahaye

Citation:

Envoyé par Spootnik

Mon problème est surtout d'être certain que l'adresse du premier objet d'une structure est la même que l'adresse de la structure.

C'est garanti par le langage, mais je ne vois pas trop à quoi ça peut te servir...
21/12/2008, 16h37
diogene

La norme n1256 précise bien :

Citation:

6.7.2.1 Structure and union specifiers
....

13 Within a structure object, the non-bit-field members and the units in which bit-fields reside have addresses that increase in the order in which they are declared. A pointer to a structure object, suitably converted, points to its initial member (or if that member is a bit-field, then to the unit in which it resides), and vice versa. There may be unnamed padding within a structure object, but not at its beginning.
21/12/2008, 18h17
Ceylo

Citation:

Envoyé par Emmanuel Delahaye

C'est garanti par le langage, mais je ne vois pas trop à quoi ça peut te servir...

À être sûr que si je "cast" mon TAD (ayant en premier membre un pointeur sur la structure de gestion des références) en TAD générique (ayant pour seul membre un pointeur sur la structure de gestion des références), j'aurai un accès garanti à mes informations.

Citation:

Envoyé par diogene

La norme n1256 précise bien : [...]

Merciii ! C'est exactement ça dont je voulais être sûr :) .
22/12/2008, 00h01
Emmanuel Delahaye

Citation:

Envoyé par Spootnik

À être sûr que si je "cast" mon TAD (ayant en premier membre un pointeur sur la structure de gestion des références) en TAD générique (ayant pour seul membre un pointeur sur la structure de gestion des références), j'aurai un accès garanti à mes informations.

J'ai du mal à voir pourquoi tu as besoins de ça. Ici, il s'agit de manipuler des données. On n'a rien à faire du fait qu'elles soient consécutives. Un pointeur void * sur un bloc suffit pour être générique. J'ai commis la même erreur il y a longtemps :

http://emmanuel-delahaye.developpez.com/clib.htm
Module Q

erreur que j'ai corrigée par la suite :

Module GFIFO.
Module GLL.
Module FARR.
Module FSTR.
22/12/2008, 22h05
Ceylo

Citation:

Envoyé par Emmanuel Delahaye

J'ai du mal à voir pourquoi tu as besoins de ça.

Parce que le gestionnaire de références ne connaît pas le contenu des structures définissant mes TADs. La seule règle qu'il suppose est que le premier membre du TAD est un pointeur vers la structure de gestion des références.
24/12/2008, 09h21
acx01b

salut

historiquement, le C++ était un espèce de gros préprocesseur qui convertissait le code en C,
et l'héritage était logiquement implémenté comme ça

c'est exactement ce que tu fais ici, simuler l'héritage de données membre