Design pattern - C++ - Programmation
Marsh Posté le 02-02-2003 à 01:53:08
bon, je vois que ca n'inspire pas trop, en clair comment vous faites pour avoir un objet global accessible en lecture / ecriture en c++ sans coder comme des bourrins...?
Marsh Posté le 02-02-2003 à 06:41:13
Je comprends pas trop...
Le seul truc qui puisse empêcher de modifier un objet est sa constance, et 'mutable' le contourne.
Marsh Posté le 02-02-2003 à 11:47:01
Citation : c'est que le singleton impose un caractere static (normal) mais donc mes classes dérivée une fois déclaré ne peuvent plus etre modifiée (du style mettre un flag privé à jour ds cette classe lors de son utilisation), |
??? un objet global et static ne peut pas etre modifie?
mais d'ou tu sors ca ?
LeGreg
Marsh Posté le 02-02-2003 à 17:42:34
bon, alors expliquez mois le pb suivant... voilà ma classe de
base:
template <typename T> class Singleton
{
static T* alone;
public:
Singleton( void )
{
assert( !alone);
alone = static_cast <T*> (this);}
~Singleton( void )
{ assert(alone); alone= 0; }
static T& Get( void )
{ return *alone; }
static T* GetPtr( void )
{ return alone; }
};
template <typename T> T* Singleton <T>::alone= 0;
maintenant, je dérive:
class derivee : public Singleton <drivee>
{
int flag;
public:
void setflag(int x) {flag=x;}
derive(){flag=2;}
};
un alias:
#define TRUC derivee::Get
main()
{
TRUC.setflag(3);
}
ca compile, je link et au lancement je plante avec segmentation fault, un recup (get), pas de pb mais un set, pb.... j'en est deduis que ca venais de la sticite du singleton, je me suis mis aux design pattern recement, je n'ai peut-etre pas capté qq chose mais une fois initialise, comment on le modifie...le constructeur...pas de pb, mon flag est bien a 2 mais apres je ne paux plus le modifier, je suis p'tet un abrutit mais j'aimerai bien comprender, je compile ss linux avec gcc 3 (je lance une fenetre glx, qui plante des que je veux ecrire ds le variables de la classe apres sa declaration....)
merci pour l'aide.
Marsh Posté le 02-02-2003 à 18:08:07
stun peu hard le assert quand meme, surtout en DNDEBUG....tu devrais peut etre préférer un autre type d'assertions plus évolués ou générer des erreurs à la compilation
plus sérieusment, ça dépend de l'emploi, mais dans les cas que je traite, je préfère avoir plusieurs instances logiques référents au meme singleton plutot que faire planter le programme à l'exécution.
Marsh Posté le 02-02-2003 à 18:14:59
au fait c'est gcc 2.95...desole
++Taz > je ne suis pas sur de comprendre, d'ou viendrait le plantage d'apres toi? des asserts du singleton? quelle technique utiliser, un singleton generique dont derive toutes les classes n'est pas adapté?
Marsh Posté le 02-02-2003 à 18:23:07
ben oui, c'est inacceptable de constater le mérpis du singleton à l'execution, cela doit etre controler beaucoup plus tot ou correctement gérer.
vas voir les static_assert sur www.boost.org
sinon je pensais à aulieu de mettre un assert, et bien si ton pointeur vaut 0, on peut lui affecter une valeur sinon la référence est partagée.
Marsh Posté le 02-02-2003 à 19:18:06
Apparment, le pb ne vient pas des assertion, les classes derivées du singleton fonctionnent tres bien à l'exécution mais je ne peux pas accéder en écriture aux variables privées de ses memes classes, c'est la que cela plante à l'exécution...
Marsh Posté le 02-02-2003 à 19:21:41
il faut que tes fonctions membres soient statiques pour pouvoir les utiliser sans instancir d'objet donc sans this
Marsh Posté le 02-02-2003 à 19:33:05
le singleton en lui meme ne m'interesse pas directement, ce sont les classes qui en derive comme on peut le voir plus haut, j'instancie ma classe derive via le #define pour simplifié l'utilisation dans le projet, quand au niveau du singleton,les fcts membres sont statics, le pb est la manipulation des données privées ds la classe derivee. Je suis debutant sur les design pattern et ne connais pas encore ts les rouages...
Marsh Posté le 02-02-2003 à 19:38:39
>> le singleton en lui meme ne m'interesse pas directement
c'est fort dommage
>> j'instancie ma classe derive via le #define
non, tu définis une commande pour le préprocesseur.
#define TRUC derivee::Get
TRUC.setflag(3);
le préprocesseur transforme ça en
derivee::Get.setflag(3);
je comprends même pas comment ça peut compiler ...
Marsh Posté le 02-02-2003 à 20:59:02
c'est bien gentil, mais ca ne m'aide pas, tout ce que je veux c'est comprendre le problem et qu'on m'explique comment l'on doit coder cela pour que cela fonctionne, l'arogance ne m'est d'aucune utilité...
Marsh Posté le 02-02-2003 à 21:00:45
c'est toi qui va te calmer puisqu' on t'as déjà répondu (moi le premier)
Marsh Posté le 02-02-2003 à 21:06:25
arrogance ? ou ça ? je me demande _vraiment_ comment ça peut compiler.
tu as déjà ta réponse : pas d'instance de ta classe. si tu ne vois pas ça, ce n'est pas un problème de design pattern que tu as, c'est un problème de base de C.
Marsh Posté le 02-02-2003 à 21:56:38
vous etes bien des informaticiens, tiens....
bref, j'utilise mon objet sans pbs avec des gets, donc si c'était un pb d'instance je ne pourrais meme pas l'utiliser a ce niveau,...
me suis inspiré de ce site, alors, il est p'tet aussi con que moi alors mais lui il explique correctement et je l'en remerci...
http://www.drizzle.com/~scottb/pub [...] gleton.htm
Marsh Posté le 02-02-2003 à 22:04:40
>> vous etes bien des informaticiens, tiens....
Make sure that you?re constructing an instance of MyClass somewhere in the system before using it. How you instantiate it doesn?t matter. You can let the compiler worry about it by making it a global or local static, or you can worry about it yourself via new and delete through an owner class. Regardless of how and when you construct the instance, it will get tracked and may be used as a singleton through a common interface by the rest of the system.
je réitère : où est ton instance ?
>> bref, j'utilise mon objet sans pbs avec des gets, donc si c'était un pb d'instance je ne pourrais meme pas l'utiliser a ce niveau,...
rien à voir. un code faux peux marcher sur une portion de code, et planter dès que tu rajoutes qq chose qui n'a rien à voir.
>> me suis inspiré de ce site, alors, il est p'tet aussi con que moi alors mais lui il explique correctement et je l'en remerci...
tu viens ici en demandant de l'aide sur un problème de design pattern, ce qui laisse supposer d'un niveau avancé. visiblement tu ne connais ni le préprocesseur, ni le fonctionnement d'une classe statique, ni l'instanciation d'objets, ni l'implémentation c++ de l'objet (question en rapport au thread : où est stockée la vtable référant les méthodes que tu appelles ?)
//
alors avant de nous prendre pour des cons, révise tes bases.
la solution, on te l'a déjà dit : INSTANCIE TON SINGLETON !
Marsh Posté le 02-02-2003 à 22:36:41
Comme je l'ai dejà dit je ne suis pas informaticien de formation (juste un tronc commun), j'apprend le fonctionnement des design pattern, les threads, je ne connais pas (encore) car je n'en ais pas l'utilite mais j'aimerai apprendre dans l'avenir...,
bref, on parle bien de l'instance de la classe drivee (MyClass), ok...
j'irais reviser mes bases ca me ne derange pas du tout, je pense avoir le merite de simplement m'y interesser...
Marsh Posté le 02-02-2003 à 22:46:29
youdontcare> mais t'inquiete je connais tt cela mais je crois honnetement faire des confusions sur l'uilisation du singleton,
pour moi, un
#define g_texture texturemgr::getsingleton() renvoi un objet static de type texturemgr donc une instanciation de la classe....
effectivement, je nais pas compris le 'sens' d'instanciation dans ce cas, mais je veux bien qu'on m'explique, sans moi aussi me prendre pr un con, en tout bien tout honneur.
Marsh Posté le 02-02-2003 à 22:56:03
>> t'inquiete je connais tt cela
non.
>> pour moi, un
#define g_texture texturemgr::getsingleton() renvoi un objet static de type texturemgr donc une instanciation de la classe....
déjà dit plus haut (tu as une facheuse tendance à ne pas lire ce qu'on t'écrit), c'est le préprocesseur. au lieu d'appeler ta copine noble par son nom complet 'mademoiselle juliette de la tournevanture blanchette', tu l'appelles julie. là c'est pareil : au lieu de taper texturemgr::getsingleton(), tu tapes g_texture. le préprocesseur s'occuper de remplacer pour l'étape suivante de la compilation. il ne fait qu'un bête remplacement de texte par un autre bout de texte.
>> effectivement, je nais pas compris le 'sens' d'instanciation dans ce cas, mais je veux bien qu'on m'explique, sans moi aussi me prendre pr un con, en tout bien tout honneur.
instancier : créer un objet. tout ça c'est la base, si tu l'as appris ça n'est apparemment jamais rentré. ce n'est pas une révision que tu dois faire, c'est un réapprentissage. c'est très bien de s'intéresser aux concept haut niveau de la prog, mais si tu ne piges le bas niveau tu vas galérer comme maintenant.
Marsh Posté le 02-02-2003 à 23:16:26
eh bien c'est pas grave, je vais galérer, ca m'est egale... tres bien, creer un objet myclass, alors je ne vois pas le lien entre cet objet créé et le #define , car en effet c'est un alias mais c'est aussi un objet texturemgr qui permet de faire les operation decrites...:
je cite:
texture* wood6 = g_TextureMgr.GetTexture("wood6" );
alors ou intervient un objet instancie texturemgr bidule, je veux simplement comprendre le lien, le réapprentissage de ce qi me manque c'est mon probleme, desolée, la journee, je ne fais pas 8 h d'infos, donc, je fais ce que je peux pour reviser mes connaissance, vocab... mais merci qd meme
Marsh Posté le 03-02-2003 à 00:12:38
Ok, j'avoue ma meconaissance du systeme de fontionnement du singleton, il suffit en effet de déclarer mon singleton (derivé) pour simplement le creer en fait, de part son unicite, l'utilisation du textureMgr::Getsingleton(), accedera forcement à ce dernier... je n'avais pas saisi la philosophie et se lien,
youdontcare et ++taz > merci de m'avoir ouvert l'esprit et de me faire comprendre l'utilite de la creation d'un objet que j'avias l'impression de ne pas utiliser, j'oubliais le fondement:unicite... je vais de ce pas me replonger ds mes bouqins et mes bases, desolé pour le dérangement et merci.
Marsh Posté le 03-02-2003 à 01:01:58
Voila comment resoudre un des problemes poses par les singletons:
http://www.cs.technion.ac.il/~gabr [...] on_cuj.pdf
LeGreg
Marsh Posté le 03-02-2003 à 01:09:54
Merci beaucoup, j'en ferai bon usage car cela me parait tres interessant
Marsh Posté le 03-02-2003 à 09:42:50
Reply
Marsh Posté le 01-02-2003 à 14:22:24
Salut!
Alors voilà, je cherche une methode pour implémenter dans un projet (ici c++) un objet global et dynamic. J'utilise pour certaines chose un singleton generic (à base de template) qui me permet de donner ce caractere global, unique a certaines de mes classes (style texture manager puisqu'il y a de l'OGL) mon probleme c'est que le singleton impose un caractere static (normal) mais donc mes classes dérivée une fois déclaré ne peuvent plus etre modifiée (du style mettre un flag privé à jour ds cette classe lors de son utilisation), donc est-ce qu'il existe un pattern singleton dynamic ou une structure s'en rapprochant?