Discussion :

[Ceylo]

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 C :

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
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 C :

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

1
2
3
struct TADGenerique {
    struct gestionReferences;
};

Merci,
Spootnik

[Emmanuel Delahaye]

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 C :

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

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

[Thierry Chappuis]

Un code structuré comme cela devrait en principe fonctionner:

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
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

[Ceylo]

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.

Un code structuré comme cela devrait en principe fonctionner:

C'est bien le "en principe" qui me chagrine .

[Emmanuel Delahaye]

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...

[diogene]

La norme n1256 précise bien :

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.

[Ceylo]

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.

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

Merciii ! C'est exactement ça dont je voulais être sûr .

[Emmanuel Delahaye]

À ê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.

[Ceylo]

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.

[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