Discussion :

[kazmi]

Hello,

Voila j'ai appris c++ sur le tas donc je suis assez naze, je l utilise en mixant c et java :p
j'ai découvert y a pas longtemps les références, j'aimerai pouvoir instancier un objet par référence sans avoir a créer des objects en dehors du constructeur pour les paramètres

voici deux classes simplifiées

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
21
 
class Node
{
public :
    Node(std::string const &name, Vector3f &position) : _name(name), _position(position){}
 
private:
std::string _name;
Vector3f _position;
 
};
 
class Camera : public Node
{
public: 
       Camera(std::string const & name, Vector3f position, Vector3f  target) :
             Node(name,positon), _target(target) {}
private:
   Vector3f _target;
 
};

voici ce que je dois faire

Code :

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

1
2
3
4
5
6
7
 
 
Vector3f u(0.0f,0.0f,1.0f);
Vector3f v(0.0f,0.0f,0.0f);
std::string s="camera";
 
Camera * cam= new Camera(s,u,v);

j'aimerai le faire en une ligne mais je ne trouve pas

Code :

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

1
2
 
Camera * cam = new Camera ("camera", Vector3f (0.0f,0.0f,1.0f),Vector3f (0.0f,0.0f,0.0f));

j'ai remarqué que si j'enlève dans l'implémentation du constructeur de camera
les & ça passe. J'aimerai aussi savoir la durée de validité des références

par exemple si je fais le code précédent dans une méthode d'une classe object
et que la classe camera est un attribut de la classe object est-ce que l'initialisation reste valide ?
ex:

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
21
22
23
 
 
class MonObject
{
 
public:
    MonObject(){
      Vector3f u(0.0f,0.0f,1.0f);
      Vector3f v(0.0f,0.0f,0.0f);
      std::string s="camera";
 
      Camera * cam= new Camera(s,u,v);
    }
 
void dosomething(){
 
   // est ce que cam est correctement instanciée 
 
}
private:
Camera * cam;
 
};

et puis une petite dernière :p
J'ai une classe qui est un singleton
j'y accède comme ça, mais je ne pense pas que c'est la bonne façon

Code :

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

1
2
3
4
 
Singleton s;
s.getinstance();
s.dosometing();

J'ai essayé en utilisant un pointeur mais je n'arrive pas a lui faire obtenir
l'instance du singleton

Code :

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

1
2
3
4
5
6
 
// ne marche pas 
Singleton * s=NULL;
s->getinstance();
ou 
s = Singleton::getinstance();

Y a aussi un truc bizarre avec ma classe singleton
j'ai une classe qui en hérite
momManager : public singleton

quand je fais :

Code :

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

1
2
 
  monManager.destroy() <- methode de singleton pour delet le pointeur d'instance

et si dans mon manager j'ai mis du code dans le destructeur
ex

Code :

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

1
2
3
4
 
~MonManager(){
   delete unpointer;
 }

ca crash l'appli
donc je fais un truc dégueu du genre créer une méthode freeResources pour delete mes pointeurs avant d'appeler le destroy


Voila je suis sur que c'est des questions triviales, mais j'ai perdu pas mal de temps à chercher partout et tester des solutions qui ne marche pas donc je retourner prog en java en attendant avec impatience vos réponses.

Merci d'avance

[LittleWhite]

Bonjour,

Pour ton premier problème tu peux :

Faire cette appel :

Code :

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

Camera * cam = new Camera ("camera", Vector3f (0.0f,0.0f,1.0f),Vector3f (0.0f,0.0f,0.0f));

Si tu déclare le constructeur comme ceci :

Code :

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

Camera(const std::string& name, const Vector3f position, const Vector3f  target)

Normalement cela devrai aller mieux, car il va faire une copie de l'objet passer, pour le constructeur.
( Si je dis pas de bêtise )

Pour le singleton normalement on le récupère comme ceci :

Code :

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

Singleton* s = Singleton::getInstance();

Le getInstance est déclarée comme ceci :

Code :

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

static Singleton* getInstance(void);

Pour ton autre erreur des singletons, je ne suis pas sur que l'héritage d'un singleton soit très bon ... ( de manière générale , j'y réfléchissais, mais si quelqu'un pouvait montrer une bonne méthode pour le faire , je suis aussi preneur )
Enfin, ton problème, je pense qu'il vient du destructeur de ton objet hérité du singleton.
Il semble que tu montre que tu détruit le pointeur du singleton, dans le destructeur de l'objet hérité.

Une solution plus propre serai :

- Ton destructeur qui herite de singleton ne fasse rien qui ne concerne pas sa propre classe.
- Le destructeur du singleton détruise ce pointeur ( car je pense que c'est celui du singleton )
- Le destructeur du singleton est virtual ( pour qu'il soit appelé par le destructeur de la classe fille

Et je crois que c'est tout, mais je rappel que hérité un singleton me semble pas très juste car l'héritage casserai la règle qui permet d'avoir l'unicité du singleton

[koala01]

Salut,

Normalement, si un membre d'une classe n'est pas une référence, lorsque tu invoque le constructeur de cette classe, le membre est construit, soit en utilisant le constructeur "normal" (qui prend, ou non, des arguments), soit en utilisant le constructeur par copie.

Le membre, quel que soit la manière dont tu va "présenter" l'argument va donc toujours avoir la même durée de vie que l'instance de la classe dont il fait partie.

"L'astuce" (bien que ce soit logique), c'est que si tu ne passe pas l'argument sous la forme d'une référence, tu va observer... une première copie de la variable passée en argument pour... quelle serve de paramètre dans le constructeur, et que cette copie sera utilisée... comme paramètres du constructeur de copie qui sera appelé pour créer le membre

Au final, tu te retrouve avec deux appels bien distincts au constructeur par copie de l'argument, là où un seul aurait largement suffit, et alors que l'une des copie sera... détruite en sortie du constructeur (ce qui est normal: on sort de la portée dans laquelle l'argument est déclaré).

Maintenant, il faut savoir que, lorsque tu écrit un code proche de

Code :

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

Node("nom du noeud",Position(0.0,0.0,1.0));

la variable qui correspond à Position (et à la chaine aussi d'ailleurs) est ce que l'on appelle une "variable non nommée":

En effet, c'est une variable qui est créée spécialement pour l'appel de la fonction, qui sera détruite en sortie de la fonction (parce qu'on quitte la portée dans laquelle elle est déclarée) et pour laquelle... il n'existe aucun nom (aucun identifiant pour être plus précis) qui permette d'y accéder dans la fonction appelante.

Il se fait que le C++ a décidé d'accepter les variables non nommées lorsqu'elles sont utilisées pour être passées par valeur ou par référence constante, mais de les interdire si elle sont utilisées pour être passées par référence non constante.

La raison semble tout à fait logique: comme une variable non nommée cesse d'exister une fois que l'on sort de la fonction pour laquelle elle a été créée, et que, d'un autre côté l'utilisation d'une référence fait que toute modification dans la fonction appelée de l'objet se répercute sur la variable qui sert d'argument dans la fonction appelante, permettre la modification de cette référence revient à permettre aux gens de... travailler pour rien, avec la série de problème qui peut en résulter

D'un autre côté, si le langage accepte la création d'une variable non nommée lorsqu'elle sert au passage par valeur, c'est parce qu'il subodore que le codeur se rendra bien compte que cette variable reste "locale" à la fonction appelée, et que cette variable ne servira que comme argument "in only".

Enfin, si le langage accepte la création d'une variable non nommée lorsqu'elle sert au passage par référence constante, c'est tout simplement parce qu'elle... ne sera pas modifiée, du fait de la constance (Lapalisse n'aurait pas dit mieux )

Comme tu as sans doute maintenant compris pourquoi il était préférable de passer les types primitifs sous la forme de référence, que je présumes que tu es conscient de l'intérêt de passer une variable n'ayant pas vocation à être modifiée sous la forme constante, et que je suppose que tu aura compris pourquoi il est impossible de passer une variable non nommée sous la forme d'une référence non constante, tu devrais pouvoir en arriver à la conclusion que, des trois possibilités qui te sont données le passage par valeur est la moins bonne des mauvaises solutions, mais que le passage par référence n'est finalement devant elle que d'une courte tête

Tu comprendra donc que l'idéal sera de passer ton objet de type Position (tout comme ta std::string, d'ailleurs) sous la forme d'une... référence constante

Pour ce qu'il en est de ton problème de singleton.

Le principe de base est, comme il ne peut jamais exister qu'une et une seule instance du singleton, de créer une méthode - statique pour qu'elle ne dépende d'aucune instance de la classe qui doit être singleton - qui se chargera de vérifier s'il existe déjà une instance - statique elle aussi pour la même raison - de la classe en question, qui créera (dynamiquement) cette instance si ce n'est pas pas le cas, et qui la renverra, et, éventuellement (car d'aucuns peuvent esitmer que, de toutes manières, une fois cette instance créée, elle est sensée exister "jusqu'à l'arret de l'application" (bien que je ne partage pas forcément ce point de vue) ) une autre méthode - toujours statique pour toujours la même raison - qui se chargera de détruire l'instance "proprement" (en n'oubliant pas de faire repasser le singleton dans un état "instance non créée").

L'idée sous-jascente étant que, tant la construction du singleton que sa destruction ne doit être accessible que... au départ de ces deux méthodes

Au final, la forme minimal d'un singleton est donc fort proche de

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
21
22
23
24
25
26
27
28
class Singleton
{
    public:
        Singleton& instance()
        {
            if(!inst)
                inst = new Singleton;
            return *inst;
        }
        /* éventuellement */
        void relase()
        {
            /* delete sur NULL ne pose pas de problème ;) */
            delete inst;
            inst = NULL;
        }
    private:
        /* le constructeur est privé, mais défini */
        Singleton(){}
        /* le destructeur itou */
        ~Singleton(){}
        /* et enfin, l'instance à garder unique également */
        static Singleton* inst;
};
/* le tout, sans oublier de définir "correctement l'instance (de manière à
 * ce qu'elle n'apparaisse qu'une fois dans le code;)
 */
Singleton* Singleton::inst = NULL;

Et il faut vraiment réagir à l'aberration que représente le fait de laisser une classe hériter d'un singleton... Du moins tel qu'il est présenté ici.

En effet, le but du singleton est... de s'assurer qu'il n'y aura qu'une instance unique de l'objet.

Or, une classe qui hérite d'une autre est... capable de se faire passer pour celel dont elle hérite, ce qui fait qu'un code proche de

Code :

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

Base* b = new Derivee();

(où Base est... la classe de base et Derivee... la classe qui en hérite) est tout à fait valide.

Or, si tu envisage l'héritage, c'est - il y a de fortes chances - parce que tu prévois différents type de Manager's...

Et c'est là qu'est l'os...

Cela signifie que tu auras, vraisemblablement, un manager mettons de caméras et un autre d'effets sonores, et tu souhaiterait sans doute que... les deux puissent exister en même temps (même si tu souhaite surement qu'il n'y ait qu'une instance de chaque)...

Telle que présentée plus haut, ta classe singleton ne pourra pas servir de base à un héritage, parce que, si tu le fais, tu sera "condamné" à n'avoir qu'un instance de gestionnaire de caméra OU une instance de gestionnaire de son...

Bref, tu devra choisir en le son et l'image ... Et ce n'est pas ce que tu veux

Pourtant, du point de vue de la conception, toutes les méthodes (y compris LSP) seraient d'accord pour estimer que tant le gestionnaire de caméras que celui d'effets sonores sont susceptibles d'hériter de singleton...

Mais, il faut trouver le moyen de faire en sorte qu'ils ne se "chamaillent" pas pour décider duquel existe à un moment T...

Ce n'est donc pas un héritage "classique" qu'il faut envisager, mais plutôt ce que l'on pourrait appeler un "héritage comportemental", de manière à ce qu'en aucun cas le gestionnaire de caméra ne puisse se faire passer pour celui d'effets sonores.

Par "chance" le C++ fournit le moyen de le faire, en utilisant l'idiome connu sous le terme barbare de "CRTP" (acronyme de Curriouly Recurriing Template Patern, ou, si tu préfères en francais, le patron modèle curieusement récursif).

L'idée est de transofrmer la classe "mere" (Singleton, dans l'exemple) en classe template, ce qui se fait "relativement" facilement sous la forme de

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
21
22
23
24
25
26
27
28
29
30
31
32
33
34
template<class T>
class TSingleton
{
    public:
        T& instance()
        {
            if(!inst)
                inst = new T;
            return *inst;
        }
        /* éventuellement */
        void relase()
        {
            /* delete sur NULL ne pose pas de problème ;) */
            delete inst;
            inst = NULL;
        }
    protected:
        /* le constructeur est protégé maintenant, pour être accessible
         * depuis le constructeur des classes dérivées
        */
        TSingleton(){}
        /* le destructeur itou */
        ~TSingleton(){}
    private:
        /* et enfin, l'instance à garder unique également */
        static T* inst;
};
/* le tout, sans oublier de définir "correctement" l'instance, en veillant
 * cette fois, vu que c'est une classe template, à ce que ce soit
 * accessible depuis le fichier d'en-tête 
 */
template <class T>
T* TSingleton<T>::inst = NULL;

Et nous pourrons implémenter ce patron de modèle curieusement récursif sous la forme de

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
class 
CamManager : public TSingleton<CamManager>
{
    public:
        /* il faut donner à la classe mère l'acces au constructeur
         * et au destructeur 
         */
       friend class TSingleton<CamManager>;
        /* les méthodes qui doivent être accessibles viennent ici*/
    private:
        /* Le constructeur et le destructeur sont privés */
        CamManager(){}
        ~CamManager(){}
        /* de même que les membres "qui vont bien ;) */
};

De cette manière, si tu décide de créer un SoundManager, ce sera sous la forme de

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
class 
SoundManager : public TSingleton<SoundManager >
{
    public:
        /* il faut donner à la classe mère l'acces au constructeur
         * et au destructeur 
         */
       friend class TSingleton<SoundManager >;
        /* les méthodes qui doivent être accessibles viennent ici*/
    private:
        /* Le constructeur et le destructeur sont privés */
        SoundManager (){}
        ~SoundManager (){}
        /* de même que les membres "qui vont bien ;) */
};

et il n'entrera pas en "collision" avec CamManager, parce que l'un hérite de TSingleton<SoundManager > et l'autre de TSingleton<CamManager> qui sont deux type différents générés par le compilateur au moment de la compilation

[LittleWhite]

Merci Koala01 pour avoir présenté le "Curriouly Recurriing Template Patern"
Je ne sais pas si je vais m'en servir immédiatement, mais maintenant au moins je sais que cela existe
Peut tu donner un bon lien qui explique pleinement ce pattern. ( Même si j'ai compris ce que tu montre, c'est pour garder un lien dans les favoris ... )

[poukill]

http://en.wikipedia.org/wiki/Curious...mplate_Pattern

[kazmi]

Alors a vous deux merci beaucoup mais alors beaucoup pour le cours et tout
c'est vraiment cool, on est vraiment chouchouté sur ce forum.

Je crois que maintenant les références c'est bon, "référence constante" partout dans mes constructeurs
ça évite l'appelle au constructeur de copie et comme ça on gagne du temps ok mais alors quelle est l'utilité des deux autres

Sinon pour le singleton, mon problème était en fait plus simple
j'aurai quand même appris les noms des patterns
en fait je n'arrivais pas à récupérer l'instance de classe dans un pointeur

Code :

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

1
2
3
4
5
6
 
// ne marche pas 
Singleton * s=NULL;
s->getinstance();
ou 
s = Singleton::getinstance();

Je sais c'est débile
du coup, voici un façon qui marche mais c'est pas plus propre en fait

Code :

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

1
2
3
4
 
Singleton * s=NULL;
s = & Singleton::getinstance();
s->dosomething();

voici mon template de singleton, y a un truc dont je suis quand même pas certain, c'est la nécessité de l'unlock() du mutex;

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
21
22
23
24
25
26
27
28
29
30
31
32
33
34
 
template <class T>
class Singleton
{
 
public:
    static T& getinstance(){
        m.lock();
        if(!inst)
            inst= new T;
        m.unlock();
        return *inst;
    }
 
    static void destroy(){
        delete inst;
        inst= NULL;
    }
 
protected:
        Singleton(){}
        ~Singleton(){}
 
private:
    Singleton(const Singleton&);
    void operator = (const Singleton&);
 
private:
    static boost::mutex m;
    static T *inst;
 
};
template<class T> boost::mutex Singleton<T>::m;
template<class T> T* Singleton<T>::inst = NULL;

[koala01]

Sauf erreur, un mutex doit être initialisé...

Quel est le meilleur moment pour le faire que lors de... la création du mutex

Ceci dit, je ne placerais cette initialisation que lors de la... première construction de l'instance de ton singleton, pour éviter que, si un autre thread demande l'instance, le mutex ne soit changé de manière indue.

La modification est mineur: il "suffit" de placer unlock dans... la condition if(inst)

Cela donne

Code :

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

1
2
3
4
5
6
7
8
9
    static T& getinstance(){
        m.lock();
        if(!inst)
        {
            inst= new T;
            m.unlock();
        }
        return *inst;
    }

Quant à la récupération de l'instance, c'est "simplement" parce que tu ne doit pas à proprement parler travailler avec un pointeur...

En suivant l'exemple donné (que ce soit la version "template" ou non), il te suffit d'écrire, au moment où tu as besoin d'une instance de ton singleton, quelque chose proche de

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
Singleton ms = Singleton::instance();
ms.doSomething();
/* ou si tu veux un CamManager */
CamManager cm = CamManager::getInstance();
cm.doSomething();
/* ou encore, car, la méthode (get)instance() peut effectivement
 * renvoyer un pointeur sur l'instance unique
 */
/* Pourquoi devrait on initialiser le pointeur à null si c'est...
 * pour lui donner tout de suite après l'adresse d'un pointeur
 * dont on est sur qu'il existe :question:
 * (n'oublie pas le "sacro saint" principe de déclarer les variables
 * uniquement quand elles sont nécessaires ;)
 */
Singleton *ms = Singleton::instance();
/* ou, dans la version utilisant CRTP */
SoundManager  *sm = Singleton::instance();

Enfin, si je t'ai parlé du CRTP, c'est parque que tu parlais d'une classe héritant de Singleton, et que, d'expérience, si une classe hérite d'une classe de base, on est souvent tenté de permettre à une autre classe d'hériter aussi de cette classe de base (et parfois même de la classe dérivée).

CRTP ne permettra pas d'hériter de la classe dérivée (pas question de faire un héritage sur CamManager ou sur SoundManager), mais, au moins, tu pourra envisager d'avoir autant de classes singleton que tu voudra

[LittleWhite]

http://en.wikipedia.org/wiki/Curious...mplate_Pattern

Merci, j'avais trouvé, mais je voulais juste une source un peu plus professionnelle. ( La wiki n'est pas toujours trop toléré par les profs ... :s ) Donc je cherchais une source autre ... n'en n'ayant pas trouvé ... je vais quand même garder la wiki dans un coin. Merci

[koala01]

A vrai dire, le CRTP est un idiome qui n'est du qu'à certaines absences du C++ et qui est - à tord - considéré comme "exotique"...

Ceci explique sans doute le fait qu'il y ait finalement peu d'articles pour le présenter

Et pourtant, c'est une approche qui permet une abstraction bien meilleure des éléments tout en gardant une souplesse de conception presque déconcertante.

Si l'anglais ne te rebute pas trop, tu peux toujours utiliser l'article de Dr dobb qui le présente

[LittleWhite]

Merci pour ce deuxième lien ( l'anglais m'embête pas du tout )

[kazmi]

Thx pour le mutex, et aussi pour les liens
I appreciate