[capilotracté]Filtrer les métodes d'une classe inconnue car reçue en template

Bonjour a tous

Suite à un certains projet assez tordu à la base, j'en suis venu, pour résoudre un certain nombre de problèmes successif, à avoir besoin d'une classe un peu particulière.....

En effet, cette classe est template, par exemple comme cela :

Code:

---

template<class objet> class Maclasse{};

---

Or cette classe va contenir un tableau de pointeurs sur des objets (ceux template) mais elle doit empêcher que ceux-ci soient détruits sans qu'elle ai auparavant effectué un traitement préalable .

J'ai donc naturellement pensé à allouer dynamiquement les objets, mais le problème est que l'utilisateur doit avoir la possibilité d'accéder à ces objet et d'en appeler les méthodes... mais pas de les supprimer...
La fonction doit donc pouvoir transmettre toutes les méthodes des objets qu'elle contient, mais interdire leur destruction ou du moins gérer cette destruction au travers d'une fonction spéciale... (en supposant que les objets n'ont pas de méthode d'autodestruction a part ~objet(); ) (je sait, on se croirais dans Fonction Impossible).

donc, maintenant que les prémices sont finies, posons les questions:

Citation:

---

Envoyé par Votre mission, si vous l'acceptez, est de répondre à cette question

1. Est-ce réalisable ou du moins envisageable ?
2. Si oui comment ? sinon, peut-on contourner la difficulté ?
3. Avez-vous mal à la tête comme moi ? :aie:

---

Bref, si vous avez une solution meilleure que le tube d'aspirine, Merci de me la soumette et toutes mes excuse si ce sujet vous a fatigué.

Merci d'avoir lu jusque là et bonne chance si vous comptez y réfléchir. :mrgreen:

Cordialement

Méphistophelès


PS:

Citation:

---

Envoyé par ce message s'autodétruira dans 3 secondes, 3, 2, 1...

BOUM !

---

Ben file un handle-proxy à tes utilisateurs, et seul toi sera à même de déclencher sa destruction et tout ce qui est dessus en cascade.

Citation:

---

Envoyé par Luc Hermitte

[...] handle-proxy [...]

---

? quésako ?

désolé, c'est une contrainte personelle est je ne suis pas pro, comme je suis quelque-peu tordu, je me casse la tête a résoudre ce problème...

Sinon, pourrais-tu expliciter ce qu'est un handle proxy ? (google n'a pas pu m'aider...)

merci

Je vois pas en quoi fournir des références vers ces objets n'est pas suffisant ?
La durée de vie est gérée par ton conteneur, donc les utilisateurs n'ont pas à détruire tes objets. Qui serait assez stupide pour faire un delete sur une référence de toutes façons ? (enfin, y'a bien des gens qui font des delete en dehors de destructeurs, alors pourquoi pas...)

disons qu'à la limite, ce serait acceptable si je pouvais détecter un delete sur un des objet, même apres que ce soit fait... le problème est que justement, l'auteur pourrais être ammené à détruire un objet mais il serait utile qu'à cette occasion, ma classe modifie un certains nombre de valeurs...

Un truc genre (il y a de l'enrobage à faire) :

Code:

---

1 2 3 4 5 6 7 8 9

class ObjectHandle { public: ObjectHandle(object* initValue); void destroy() {/*Tu fais ce que tu veux ici*/} object* operator->() {return myObj;} private: object *myObj; };

---

Et tu retourne cet objet partout.
Peut-être un simple shared_ptr avec un custom deleter ferait aussi ce que tu veux.

Citation:

---

Envoyé par JolyLoic

Un truc genre (il y a de l'enrobage à faire) :

Code:

---

1 2 3 4 5 6 7 8 9

class ObjectHandle { public: ObjectHandle(object* initValue); void destroy() {/*Tu fais ce que tu veux ici*/} object* operator->() {return myObj;} private: object *myObj; };

---

---

Heuuuu en fait, je ne vois pas en quoi cela empêche l'appelant de faire un delete myobj (à moins que destroy ne soit automatiquement appelé à ce moment là, mais je vois pas pourquoi...) :?

Citation:

---

Envoyé par JolyLoic

Peut-être un simple shared_ptr avec un custom deleter ferait aussi ce que tu veux.

---

Citation:

---

Envoyé par Doc boost

The shared_ptr class template stores a pointer to a dynamically allocated object, typically with a C++ new-expression. The object pointed to is guaranteed to be deleted when the last shared_ptr pointing to it is destroyed or reset. See the example.

---

Il me semble que le shared_ptr permet de détruire un objet pointé lorsque le shared_ptr est détruit, mais ce qui m'interesserait serait de "réagir" à la destruction ou qu'elle se fasse....

En tout cas, merci à tous de vous écheveler pour ça. :fou:

Citation:

---

Envoyé par méphistopheles

Heuuuu en fait, je ne vois pas en quoi cela empêche l'appelant de faire un delete myobj (à moins que destroy ne soit automatiquement appelé à ce moment là, mais je vois pas pourquoi...) :?

---

L'utilisateur n'a simplement pas accès à myObj, comment pourrait-il faire delete dessus ? La seule chose qu'il pourra faire, c'est appeler destroy, qui fera ce que tu veux que ça fasse.

Citation:

---

Envoyé par méphistopheles

Il me semble que le shared_ptr permet de détruire un objet pointé lorsque le shared_ptr est détruit, mais ce qui m'interesserait serait de "réagir" à la destruction ou qu'elle se fasse....

---

Le custom deleter permet de spécifier que le shared_ptr, au lieu de simplement appeler deleter sur le pointeur pour détruire l'objet pointé, doit faire autre-chose.

Citation:

---

Envoyé par JolyLoic

L'utilisateur n'a simplement pas accès à myObj, comment pourrait-il faire delete dessus ? La seule chose qu'il pourra faire, c'est appeler destroy, qui fera ce que tu veux que ça fasse.

---

ben: en reprenant ton code, on pourrais faire:

Code:

---

1 2 3

ObjectHandle monobjet(&unobjet); [...] delete monobjet->;//équivalent à delete monobjet.myObj non ?

---

Citation:

---

Envoyé par JolyLoic

Le custom deleter permet de spécifier que le shared_ptr, au lieu de simplement appeler deleter sur le pointeur pour détruire l'objet pointé, doit faire autre-chose.

---

oui, mais l'objet qu'on me passera en paramètre ne sera pas forcément un shared_ptr... et comme le but est d'éviter qu'un appel externe ne détruise directement l'objet et non qu'un destructeur de la classe aie un effet sur l'objet...

Citation:

---

Envoyé par JolyLoic

L'utilisateur n'a simplement pas accès à myObj, comment pourrait-il faire delete dessus ?

---

Code:

---

delete h.operator->();

---

Citation:

---

Envoyé par Jean-Marc.Bourguet

Code:

---

delete h.operator->();

---

---

Effectivement. Je me plaçais dans le cas où l'on voulait empêcher que l'utilisateur fasse par mégarde un delete sur l'objet. Pas dans celui où l'on veut l'empêcher de faire sciemment et dans une intention de nuire un delete sur l'objet.

Dans le second cas, faire un proxy complet (implémenter dans ObjectHandle toutes les fonctions de object, et ne pas donner un accès au pointeur du tout) permet de penser qu'on a résolu le problème. Mais comme de toute façon, des comportements indéfinis comme #define private public ont toutes les chances de marcher quand même, je ne vois pas trop quel mécanismes le C++ peut apporter contre une personne mal intentionnée.

Citation:

---

Envoyé par JolyLoic

Effectivement. Je me plaçais dans le cas où l'on voulait empêcher que l'utilisateur fasse par mégarde un delete sur l'objet. Pas dans celui où l'on veut l'empêcher de faire sciemment et dans une intention de nuire un delete sur l'objet.

Dans le second cas, faire un proxy complet (implémenter dans ObjectHandle toutes les fonctions de object, et ne pas donner un accès au pointeur du tout) permet de penser qu'on a résolu le problème. Mais comme de toute façon, des comportements indéfinis comme #define private public ont toutes les chances de marcher quand même, je ne vois pas trop quel mécanismes le C++ peut apporter contre une personne mal intentionnée.

---

ce n'est pas vraiment une question de mauvaises intentions, l'utilisateur pourrait avoir besoin de faire un delete sur l'objet, mais il faudrais que je "capte" ce delete. sinon, comment surcharger toutes les fonction de object si on ne le connais pas ? (c'est un template)....

Si l'utilisateur a besoin de supprimer, il trouvera sûrement un peu tordu d'utiliser le ->.

Un utilisateur, s'il fait un ->, sais qu'il est face à un handle, et donc qu'il y a des précautions à prendre. Un minimum de documentation sur ton code et il saura pour sûr qu'il faut utiliser la fonction destroy() du handle, au lieu de faire le delete directement.

Les mot-clefs public, private... sont à la base pour aider les utilisateurs à éviter des heures de débugs. Pas pour les empêcher de faire des choses 'mal intentionnées'.

L'autre problème est que les objets sont stockés dans une matrice... et donc que je dois avoir un appel du type (x,y)....

ce qui rend l'opérateur"->" un peu difficile à mettre en place... quand à ne pas utiliser d'opérateur, ce serait vraiment en dernier recours...

Faire une matrice d'handles?

C'est à dire une classe qui gère un tableau d'handles, ainsi tu peux faire objet[x]->...

hmmm ok, je vois, merci beaucoup :D

par contre, ça ne risque par d'alourdir la compilation ?


Sinon, j'ai lu un tuto sur les itérateurs et je me demandais si c'étais possible de s'en sortir avec des Input et des Output mais le problème reste celui de savoir quelles sont les méthodes de la classe :?

Enfin, sinon, j'ai une solution de rechange. merci

Citation:

---

Envoyé par méphistopheles

Est-ce réalisable ou du moins envisageable ?
Si oui comment ? sinon, peut-on contourner la difficulté ?
Avez-vous mal à la tête comme moi ?

---

une solution théorique serait l'instrumentation du code…
regardez du côté d'AspectC…

J'ai problablement loupé quelque chose, mais comme l'a suggéré Loufoque, je ne vois pas pourquoi tu aurais besoin de pointeurs et d'allocation dynamique, à moins que, comme souvent, le véritable problème se situe ailleurs, dans un contexte qui n'est pas décrit par les précédents posts.

Si tu crées directement un tableau d'objets en tant que donnée-membre de ta classe et non un tableau de pointeurs sur des objets, eux, créés dynamiquement, alors le problème est résolu de lui-même : l'utilisateur ne pourra détruire ni le tableau ni un de ses membres sans détruire l'instance de la classe entière.

Si tu as besoin d'envoyer un signal à une autorité particulière à la disparition d'un objet (pour compter des références ou que sais-je), tu peux aussi remplacer tes classes templates par une classe unique de ton choix, et faire dériver tous les autres objets de celle-ci. Tu utilises donc le concept de l'interface (avec en plus les données de gestion), pour n'utiliser que des classes compatibles avec les manips que tu veux leur faire subir.

Si la taille de ton tableau est variable et que c'est dans la nature de la classe de gagner ou perdre des objets, c'est à la classe elle-même qu'il faut le demander, à mon avis, au travers de méthodes adéquates. Sinon, dans tous les cas, le mieux que tu aies à faire est d'utiliser une classe-conteneur intelligente. Donc soit std::vector<>, soit un conteneur de ta création, voire même un dérivé du précédent. Ainsi, tu peux renvoyer des références sur les éléments.

Avec ces approches, tu peux toujours contrôler, à mon avis, l'étape de destruction.

Je crois finalement avoir trouvé la solution.

Il est apparement possible d'hériter d'un template.
En définissant une classe héritant du template, classe dont ma classe principale sera amie, il apparait qu'il suffit de redéfinir l'opérateur delete pour avoir la possibilité d'exécuter un petit script avant que l'objet ne soit détruit.
Avec un peu de chance, le polymorphisme s'appliquera bien et je n'aurais même pas besoin de redéfinir les constructeurs par copie du template.(enfin là, je rêve un peu :roll:).

Bon, y'a plus qu'à comme on dit.

Merci à tous, je m'y attache de pied ferme :aie: