Discussion :

[vandamme]

Voila, j'ai une classe du type :

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 Widget
{
  public:
    Widget() : s_(0) {}
    ~Widget() {  delete s_; s_ = 0; }  
 
    void execute()
    {
      s_.apply();
    }
 
    void setStrategy(Strategy* s)
    {
      if (s_ != 0)
        delete s_;
      s_ = s;
    }
 
  private:
   Strategy* s_;
}

Voila, rien d'extraordinaire jusque la , mais supposons, qu'au lieu de faire :

Code :

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

widget.setStrategy(new Strategy)

Je fasse :

Code :

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

widget.setStrategy(&Strategy())

Dans ce derner cas, la classe Widget appelera un delete sur un objet alloue sur la pile ....
Donc, je voulais savoir comment s'en sortir dans ce cas ?
Je sais qu'on pourrait surcharger et encapsuler en private ::operator new pour eviter de faire un new Strategy et supprimer le delete dans la classe Widget, mais existe - t - il d'autres moyens ?

[Davidbrcz]

Déjà dans ton 2eme cas ton compilo devrait t'avertir que tu prend l'adresse d'un objet temporaire qui ne sera plus valide dès la fin de l'instruction.

Pour éviter ce genre de problème, on pourrait dans setStrategy effectuer une copie de la stratégie via Prototypage (cela revient à dire que le widget est le gestionaire de la stratégie) . Par contre on à une gaspile de mémoire si on continue à passer l'objet en paramètre via pointeur car on ne sait pas comment il à été alloué. Pour éviter cela, il faudrat le passer en référénce constante puis le cloner.

Ca donnerai un truc du genre :

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
 
class Widget
{
  public:
    Widget() : s_(0) {}
    ~Widget() {  delete s_; s_ = 0; }  
 
    void execute()
    {
      s_.apply();
    }
 
    void setStrategy(const Strategy& s)
    {
      s_ = s.Clone();
    }
 
  private:
   Strategy* s_;
}

Et quelque chose comme :

Code :

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

widget.setStrategy(Strategy())

passerai sans problème.

EDIT: code non testé.

[vandamme]

oui, en effet setStrategy(&Strategy()) genererait un warning,

Code :

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

1
2
3
 
Strategy s;
setStrategy(&s)

aurait deja ete plus logique.

Et sinon, plutot que de faire un clonage qui provoque une construction supplementaire, que penserait tu d'encapsuler la creation du ptr Strategy* dans un auto_ptr et de n'utiliser que ce auto_ptr dans la classe Widget ?

on aurait dans Widget :

Code :

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

setStrategy(auto_ptr<Strategy> s) {...}

[zais_ethael]

Ton problème est que tu as une entité (ici un objet) qui veut gérer le cycle de vie d'un objet construit par une autre entité (dans ton exemple la pile, mais ça pourrait aussi bien être un autre objet) mais ta syntaxe n'oblige pas à déléguer la gestion de ce cycle de vie.

L'utilisation du clonage est une façon de contourner ce problème, mais ce n'est pas ce que tu voulais faire au départ.

Donc je te conseillerais exactement la même chose que vandamme. L'auto_ptr est très utile dans ce genre de cas, en passer un par valeur à une fonction enlève toute possibilité pour l'entité appelante de conserver la gestion du cycle de vie de l'objet, bref exactement ce dont tu as besoin.