Discussion :

[Higestromm]

Bonjour,

Je suis en train de créer une application Qt dont une donnée doit être partagée par plusieurs classes.

Afin d'éviter de me prendre la tete (en theorie) j'ai décider de dériver mon objet partagé avec un QSharedData et de recupérer un singleton sous la forme d'un QSharedDataPointer<maclasse>.

Jusque la pas de souci.

La ou ca se complique c'est quand je veux utiliser un fonction de mon objet partagé... Tout les acces partagés avec l'operateur -> sont soit constants (pas de modifications possibles) soit il me fait une copie de l'objet.

Il n'y a pas un moyen de modifier mon objet tout en restant partagé ?

Je préfère croire que j'ai mal lu la doc

Quelqu'un a une idée ?

Merci

[Matthieu Brucher]

Bizarre, d'après la doc, ça doit passer !
Le singleton a un const quelque part ?

[Higestromm]

Bizarre, d'après la doc, ça doit passer !
Le singleton a un const quelque part ?

Justement non. Et c'est ca le probleme. Ma classe contient des QMutex qui empechent ma classe d'utiliser l'operateur = par exemple (les mutex possedent des contructeurs par copie en privée).
Du coup mon compilateur hurle en me disant que le smartpointer tente de faire une copie alors que les méthodes de copie sont privées.

Je pourrais bien m'arranger pour que ma classe puisse utilisée des constructeurs par copie en surchargant 2 ou 3 fonctions mais cela ne résoudrais pas mon probleme qui est que si mon pointeur n'est pas constant, la methode -> de QSharedDataPointer appele la méthode detach() qui créer une copie de mon objet.

Dans la doc, toute les méthode permettant d'acceder au pointer "non const" appelent la méthode detach()

En attendant j'utilise un pointeur classique et j'aimerais éviter d'utiliser Boost juste pour ca :/

Help !

[epsilon68]

ce n'est pas fait pour ca les shared data dans Qt.
C'est fait pour eviter les recopies d'objets, tout en gardant l'independance des objets entre eux, si tu le modifie il se copie automatiquement. Comme ca tu peux par exemple passer une QString en parametre sans forcement la passer en ref & ou en pointer *
Aussi quand on la retourne d'une fonction, elle ne se recopie pas tout le temps.

Je ne comprend pas bien son utilisation dans ton cas qui est un singleton ?
qu'est ce qui te gene dans un simple pointer ?
il faudra aussi dans tous les cas gerer les acces concurrent ...

Si c'est le pointer en lui-meme qui te gene, tu peux l'encapsuler dans un objet et tu ne verras plus le pointer.

Explique juste un peu plus ?

[Higestromm]

Ce qui me geine c'est que mon singleton sera utilisé par des modules (programmer par je ne sait pas qui) qui pourraient avoir la mauvaise idée de vouloir le delete. Cela rendrais donc mon programme instable a cause d'un module mal programmé.

En utilisant un SmartPointer j'évitait toute destruction de pointeur de manière inoportune.

Ceci dit c'est peut etre une mauvaise solution à mon problème.

[Matthieu Brucher]

Peut-être alors en regardant chez Boost ? Ca ne coûte rien de voir : http://miles.developpez.com/tutoriel...ost/smartptrs/

[epsilon68]

tu ne pourra pas empecher d'utiliser delete sur cet objet.
c'est clair, tu autorises tout le monde a modifier ton objet,
donc il est partagé.... et donc les clients doivent respecter son utilisation.

cependant une solution serait peut-etre de faire une facade qui serait un objet par recopie, contenant ton pointer.

MonObjet *monPointer = new MonObject; // pointer singleton

MaFacade facade( monPointer );
facade::mafonction() { m_monPointer->mafonction(); }

MaFacade Singleton::getShareObject() { return MaFacade(monPointer); }

Dans cette solution il n'y a plus de pointer apparent, plus de delete donc.
un peu plus lourd parce qu'il faut re-encapsuler les fonctions.
Mais bon pas mal d'avantages quand meme.

A+

[Higestromm]

Pas bête Je vais me pencher la dessus.

Par contre si j'utilise un smart pointer, comment est il possible qu'un delete soit effectuer alors qu'il y a encore un utilisateur sur cet objet ?

[epsilon68]

Je pense que SmartPtr resoudrait aussi ton probleme,
mais utiliser un compteur de reference juste pour un singleton,
et juste pour eviter que les clients fassent un delete... bof
mais ca marcherait....

dis-nous laquelle solution tu vas prendre, et si tu es content avec
essaie peut-etre les deux

moi j'eviterai d'ajouter des dependances comme ca, surtout en utilisant Qt
j'eviterais les points de maintenance sur les differentes plateformes... meme si c'est boost

[Matthieu Brucher]

Sachant que certains smart pointers seront dans le standard à venir, est-ce vraiment un problème ?

[Higestromm]

Bah en fait apres reflexion je me suis dit que j'allais ecrire en ENORME dans la doc de ne pas faire de delete sur ce pointeur.

Après cela je vais m'en remettre au développeur du module pour qu'il s'assure que son développement ne remette pas en cause la stabilité du logiciel de base.

Pour l'instant je suis le seul et unique développeur (et ce pour un petit moment) donc rien à signaler. Si jamais je me rend compte plus tard que ce point souleve des problèmes, je prendrais les mesures nécéssaires.

[Matthieu Brucher]

Il n'y a pas moyen de faire cela en mettant le destructeur privé et l'appel au destructeur par le delete dans une fonction statique de la classe ?

[epsilon68]

un avantage pour la facade si tu dois etre thread safe
quand tu re-encapsule les functions tu peux utiliser un mutex.

en tout cas oui j'attendrais que smartptr soit standard, mais bon je persiste a dire pas la peine de l'utiliser dans le cas d'un singleton.

A noter aussi que les singletons doivent etre utilisé avec parcimonie parce que c'est une sorte de variable globale en quelque sorte ....

[Higestromm]

Il n'y a pas moyen de faire cela en mettant le destructeur privé et l'appel au destructeur par le delete dans une fonction statique de la classe ?

Je ne savais pas que l'on pouvais rendre un detructeur privé pour empécher un delete en fait :/

un avantage pour la facade si tu dois etre thread safe
quand tu re-encapsule les functions tu peux utiliser un mutex.

Bah les mutex avec Qt j'utilise avec parcimonie car je doit mal l'utiliser. Comme le construicteur par copie, par défaut et autres opérateurs d'affectation ne sont pas publique, je ne peux plus faire de copie de mes objets qui les utilisent :/

Je vais essayer de voir comment bien utiliser les Mutex avec Qt mais pour l'instant je ne pense pas être au point.

[Matthieu Brucher]

Je ne savais pas que l'on pouvais rendre un detructeur privé pour empécher un delete en fait :/

Maintenant, tu as une autre corde à ton arc

[epsilon68]

cette classe n'aurait de toute facon pas a avoir de QMutex comme variable membre mais le posseder en pointer dans son constructeur, sinon comment synchroniser les appels alors au travers des multiples instances ?

A+ & bonne chance

la voie du multi-threading est longue, semée d'embuches mais inevitable....

[epsilon68]

openmp !!!!!!!!