Pointeurs intelligents et clonage

Version imprimable

22/03/2011, 10h29
Caduchon

Pointeurs intelligents et clonage

Bonjour à tous,

Étant actuellement à la recherche d'une bonne architecture de mon code, je me penche sur les pointeurs intelligents et en particulier, je suis tombé sur le tutoriel suivant:
http://loic-joly.developpez.com/tuto...mart-pointers/

Et là il y a un point qui me pose un gros problème: Si j'ai bien compris les exemples de la partie II-C-4, la copie du pointeur implique un clonage de l'objet pointé. Sachant que mon objet pointé peut faire plusieurs Go, c'est évidemment impensable !!! :mrgreen:
Ne comprenant pas encore très bien le fonctionnement, je ne vois pas très bien quelle alternative je pourrais utiliser pour n'avoir jamais besoin de cloner mon objet pointé (ce qui me semble fort douteux, même pour des petites classes d'ailleurs, le principe du pointeur n'est il pas justement de focaliser plusieurs yeux sur les mêmes données ???)

Je suis tout ouvert à vos solutions éventuelles,

Caduchon.
22/03/2011, 10h43
dragonjoker59

En fait tout dépend du type de pointeur que tu utilises. Pour un pointeur intelligent qui a un comportement tel que tu le souhaiterais, il te faut utiliser le 'shared_ptr' qui te permet de copier le pointeur et non la donnée.
Le weak_ptr n'est pas copiable donc il ne t'intéresse pas du tout, le unique_ptr non plus du fait de sa durée de vie très éphémère.
22/03/2011, 12h41
3DArchi

Salut,

Citation:

Envoyé par Caduchon

Étant actuellement à la recherche d'une bonne architecture de mon code, je me penche sur les pointeurs intelligents et en particulier, je suis tombé sur le tutoriel suivant:
http://loic-joly.developpez.com/tuto...mart-pointers/

Excellente initiative car c'est un tutoriel de qualité sur un problème fondamental :ccool:

Citation:

Envoyé par Caduchon

Et là il y a un point qui me pose un gros problème: Si j'ai bien compris les exemples de la partie II-C-4, la copie du pointeur implique un clonage de l'objet pointé.

Oui. C'est un choix dans l'exemple de la gestion de la copie du pointeur. Il existe bien d'autre choix bien sur.

Tu peux mettre en place une gestion de la copie par le partage en utilisant un compteur de référence : mais boost::shared_ptr ou std::shared_ptr (si tu as un compilo C++0x ou implémentant TR1) l'ont déjà fait pour toi, alors pas la peine de réinventer la roue.

Une autre solution est effectivement d'interdire le partage en interdisant la copie. C'est l'objectif des boost/std::unique_ptr.

Et ainsi de suite, d'autres politiques de partage peuvent être envisagées.

Tout ça pour dire que la réponse à ta question doit d'abord être de type conception : qui va gérer le pointeur, qui va y avoir accès, quand et comment. Ce sont ces réponses qui te conduiront à identifier la politique de copie que tu dois associer à ton pointeur intelligent. Et à partir de là, le choix entre unique, shared, loic, ou autre sera évident.

J'ai finalement abouti à ceci. Ca semble fonctionner, mais je ne serais pas contre un coup d'oeil d'expert pour critiquer. :roll:

smart_ptr.h

Code:

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
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
 
#ifndef _INCL_SMART_PTR_H__
#define _INCL_SMART_PTR_H__
 
  template <class T> class make_ptr;
 
  template <class T> class smart_ptr
  {
    public:
      smart_ptr();
      smart_ptr(const smart_ptr<T>& p);
      smart_ptr(const make_ptr<T>& mkr);
      ~smart_ptr();
      smart_ptr<T>& operator = (const smart_ptr<T>& p);
      smart_ptr<T>& operator = (const make_ptr<T>& mkr);
      template <class U> operator smart_ptr<U> ();
 
      T& operator * () const;
      T* operator -> () const;
 
    private:
      smart_ptr(T* ptr_t);
 
      T* p_;
      unsigned long int* count_;
 
    template <class> friend class smart_ptr;
    template <class> friend class make_ptr;
  };
 
  template <class T> class make_ptr
  {
    public:
      make_ptr();
      make_ptr(const T& t);
      make_ptr(const make_ptr<T>& mkr);
      ~make_ptr();
 
    private:
      smart_ptr<T>	ptr_;
 
    template <class> friend class smart_ptr;
  };
 
 
 
 
 
 
 
 
  template <class T> inline smart_ptr<T>::smart_ptr() : p_(NULL), count_(NULL)
  {}
 
  template <class T> inline smart_ptr<T>::smart_ptr(const smart_ptr<T>& ptr) : p_(ptr.p_), count_(ptr.count_)
  {
    ++(*count_);
  }
 
  template <class T> inline smart_ptr<T>::smart_ptr(const make_ptr<T>& mkr) : p_(mkr.ptr_.p_), count_(mkr.ptr_.count_)
  {
    ++(*count_);
  }
 
  template <class T> inline smart_ptr<T>::~smart_ptr()
  {
    --(*count_);
    if((*count_) == 0)
    {
      delete p_;
      delete count_;
    }
  }
 
  template <class T> inline smart_ptr<T>& smart_ptr<T>::operator = (const smart_ptr<T>& ptr)
  {
    --(*count_);
    if(*count_ == 0)
    {
      delete p_;
      delete count_;
    }
    p_ = ptr.p_;
    count_ = ptr.count_;
    ++(*count_);
    return *this;
  }
 
  template <class T> inline smart_ptr<T>& smart_ptr<T>::operator = (const make_ptr<T>& mkr)
  {
    --(*count_);
    if(*count_ == 0)
    {
      delete p_;
      delete count_;
    }
    p_ = mkr.ptr_.p_;
    count_ = mkr.ptr_.count_;
    ++(*count_);
    return *this;
  }
 
  template <class T> template <class U> inline smart_ptr<T>::operator smart_ptr<U> ()
  {
    smart_ptr<U> pU;
    pU.p_ = p_;
    pU.count_ = count_;
    ++(*count_);
    return pU;
  }
 
  template <class T> inline T& smart_ptr<T>::operator * () const
  {
    return *p_;
  }
 
  template <class T> inline T* smart_ptr<T>::operator -> () const
  {
    return p_;
  }
 
  template <class T> inline smart_ptr<T>::smart_ptr(T* ptr_t) : p_(ptr_t)
  {
    count_ = new unsigned long int(1);
  }
 
  // ----------------------------------
 
  template <class T> inline make_ptr<T>::make_ptr() : ptr_(new T)
  {}
 
  template <class T> inline make_ptr<T>::make_ptr(const T& t): ptr_(new T(t))
  {}
 
  template <class T> inline make_ptr<T>::make_ptr(const make_ptr<T>& mkr) : ptr_(mkr.ptr_)
  {}
 
  template <class T> inline make_ptr<T>::~make_ptr()
  {}
 
 
#endif

Test.cpp

Code:

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
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
 
#include <iostream>
#include "tools.h"
 
  class A
  {
    public:
      virtual ~A() {}
      virtual std::string who() const = 0;
  };
 
  class B : public A
  {
    public:
      B() {}
      virtual ~B() {}
      virtual std::string who() const { return std::string("class B"); }
  };
 
  class C : public A
  {
    public:
      C() {}
      virtual ~C() {}
      virtual std::string who() const { return std::string("class C"); }
  };
 
 
 
  smart_ptr<A> generatorB()
  {
    smart_ptr<B> p = make_ptr<B>();
    return p;
  }
 
  smart_ptr<A> generatorC()
  {
    smart_ptr<C> p = make_ptr<C>();
    return p;
  }
 
  int main()
  {
    smart_ptr<A> pB = generatorB();
    smart_ptr<A> pC = generatorC();
    std::cout << pB->who() << std::endl;
              << pC->who() << std::endl;
    return 0;
  }

Si vous avez des conseils n'hésitez pas ! :ccool:

Caduchon.

22/03/2011, 17h44
N i h i l

Citation:

Envoyé par Caduchon

Si vous avez des conseils n'hésitez pas ! :ccool:

1/ Relis les conseils précédents.
2/ Utilise boost::shared_ptr.
3/ Goto 1.

4/ Quelle est la différence entre smart_ptr< A > et smart_ptr< A > const ?
5/ Que se passe-t-il la seule instance de smart_ptr< A > est x et que j'éxecute x= x; ?
6/ Si l'allocation de count_ jette une exception, que se passe-t-il ?
7/ Goto 1.

Citation:

Envoyé par Caduchon

J'ai finalement abouti à ceci. Ca semble fonctionner, mais je ne serais pas contre un coup d'oeil d'expert pour critiquer. :roll:

smart_ptr.h

Code:

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
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
 
#ifndef _INCL_SMART_PTR_H__
#define _INCL_SMART_PTR_H__
 
  template <class T> class make_ptr;
 
  template <class T> class smart_ptr
  {
    public:
      smart_ptr();
      smart_ptr(const smart_ptr<T>& p);
      smart_ptr(const make_ptr<T>& mkr);
      ~smart_ptr();
      smart_ptr<T>& operator = (const smart_ptr<T>& p);
      smart_ptr<T>& operator = (const make_ptr<T>& mkr);
      template <class U> operator smart_ptr<U> ();
 
      T& operator * () const;
      T* operator -> () const;
 
    private:
      smart_ptr(T* ptr_t);
 
      T* p_;
      unsigned long int* count_;
 
    template <class> friend class smart_ptr;
    template <class> friend class make_ptr;
  };
 
  template <class T> class make_ptr
  {
    public:
      make_ptr();
      make_ptr(const T& t);
      make_ptr(const make_ptr<T>& mkr);
      ~make_ptr();
 
    private:
      smart_ptr<T>	ptr_;
 
    template <class> friend class smart_ptr;
  };
 
 
 
 
 
 
 
 
  template <class T> inline smart_ptr<T>::smart_ptr() : p_(NULL), count_(NULL)
  {}
 
  template <class T> inline smart_ptr<T>::smart_ptr(const smart_ptr<T>& ptr) : p_(ptr.p_), count_(ptr.count_)
  {
    ++(*count_);
  }
 
  template <class T> inline smart_ptr<T>::smart_ptr(const make_ptr<T>& mkr) : p_(mkr.ptr_.p_), count_(mkr.ptr_.count_)
  {
    ++(*count_);
  }
 
  template <class T> inline smart_ptr<T>::~smart_ptr()
  {
    --(*count_);
    if((*count_) == 0)
    {
      delete p_;
      delete count_;
    }
  }
 
  template <class T> inline smart_ptr<T>& smart_ptr<T>::operator = (const smart_ptr<T>& ptr)
  {
    --(*count_);
    if(*count_ == 0)
    {
      delete p_;
      delete count_;
    }
    p_ = ptr.p_;
    count_ = ptr.count_;
    ++(*count_);
    return *this;
  }
 
  template <class T> inline smart_ptr<T>& smart_ptr<T>::operator = (const make_ptr<T>& mkr)
  {
    --(*count_);
    if(*count_ == 0)
    {
      delete p_;
      delete count_;
    }
    p_ = mkr.ptr_.p_;
    count_ = mkr.ptr_.count_;
    ++(*count_);
    return *this;
  }
 
  template <class T> template <class U> inline smart_ptr<T>::operator smart_ptr<U> ()
  {
    smart_ptr<U> pU;
    pU.p_ = p_;
    pU.count_ = count_;
    ++(*count_);
    return pU;
  }
 
  template <class T> inline T& smart_ptr<T>::operator * () const
  {
    return *p_;
  }
 
  template <class T> inline T* smart_ptr<T>::operator -> () const
  {
    return p_;
  }
 
  template <class T> inline smart_ptr<T>::smart_ptr(T* ptr_t) : p_(ptr_t)
  {
    count_ = new unsigned long int(1);
  }
 
  // ----------------------------------
 
  template <class T> inline make_ptr<T>::make_ptr() : ptr_(new T)
  {}
 
  template <class T> inline make_ptr<T>::make_ptr(const T& t): ptr_(new T(t))
  {}
 
  template <class T> inline make_ptr<T>::make_ptr(const make_ptr<T>& mkr) : ptr_(mkr.ptr_)
  {}
 
  template <class T> inline make_ptr<T>::~make_ptr()
  {}
 
 
#endif

Test.cpp

Code:

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
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
 
#include <iostream>
#include "tools.h"
 
  class A
  {
    public:
      virtual ~A() {}
      virtual std::string who() const = 0;
  };
 
  class B : public A
  {
    public:
      B() {}
      virtual ~B() {}
      virtual std::string who() const { return std::string("class B"); }
  };
 
  class C : public A
  {
    public:
      C() {}
      virtual ~C() {}
      virtual std::string who() const { return std::string("class C"); }
  };
 
 
 
  smart_ptr<A> generatorB()
  {
    smart_ptr<B> p = make_ptr<B>();
    return p;
  }
 
  smart_ptr<A> generatorC()
  {
    smart_ptr<C> p = make_ptr<C>();
    return p;
  }
 
  int main()
  {
    smart_ptr<A> pB = generatorB();
    smart_ptr<A> pC = generatorC();
    std::cout << pB->who() << std::endl;
              << pC->who() << std::endl;
    return 0;
  }

Si vous avez des conseils n'hésitez pas ! :ccool:

Caduchon.

smart_ptr<T> x = make_ptr<T>();
x = x; // boum;

Et t'es loin d'offrir les garanties d'exception safety suffisante pour ce genre de classe!
fin bref, using boost::shared_ptr;

22/03/2011, 19h46
Caduchon

Malheureusement, j'aimerais dans un premier temps éviter l'utilisation de boost. Son installation sur le cluster de mon entreprise ne dépend pas de moi et je doute que ça puisse être fait dans un délais appréciable. Je dois donc m'en passer pour le moment...
22/03/2011, 22h59
JolyLoic

La partie smart_ptr de boost ne demande pas vraiment d'installation, juste la présence des fichiers .hpp dans le répertoire d'include de ton compilateur.

En outre, la plupart des compilateur C++ pas trop vieux intègrent désormais un shared_ptr sans devoir installer quoi que ce soit. Quel compilateur utilises-tu (et quelle version ?) ?
23/03/2011, 09h57
Caduchon

Je n'ai pas encore été briefé sur le sujet. Pour le moment je retravaille le code en local avec g++ 4.2.1 (qui semble donc dater de 2007) et je n'ai pas encore été amené à me pencher sur le compilo du supercalculateur mais je pense que c'est la 4.1 qui y est installée.

Suite à vos remarques, j'ai transformé mon code à plusieurs endroits.
J'ai supprimé ma classe make_ptr au profit de deux fonctions statiques, c'est nettement plus propre :mrgreen: :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
 
  // Dans la classe:
  static smart_ptr<T> make_ptr();
  static smart_ptr<T> make_ptr(const T& t);
 
  // Hors de la classe:
  template <class T> inline smart_ptr<T> smart_ptr<T>::make_ptr()
  {
    return smart_ptr<T>(new T);
  }
 
  template <class T> inline smart_ptr<T> smart_ptr<T>::make_ptr(const T& t)
  {
    return smart_ptr<T>(new T(t));
  }

J'ai corrigé l'assignation:

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
 
  template <class T> inline const smart_ptr<T>& smart_ptr<T>::operator = (const smart_ptr<T>& ptr)
  {
    if(p_ != ptr.p_)
    {
      --(*count_);
      if(*count_ == 0)
      {
        delete p_;
        delete count_;
      }
      p_ = ptr.p_;
      count_ = ptr.count_;
      ++(*count_);
    }
    return *this;
  }

Et j'ai renforcé la possibilité de gérer les exceptions:

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
 
  template <class T> inline smart_ptr<T>::smart_ptr(T* ptr_t) : p_(ptr_t)
  {
    try
    {
      count_ = new unsigned long int(1);
    }
    catch(...)
    {
      delete p_;
      throw;
    }
  }

Je suis donc à l'écoute de vos autres remarques si vous en avez :)
NB: Je ne me suis pas encore questionné sur les const comme ça a été suggéré.

23/03/2011, 12h43
JolyLoic

D'après http://anteru.net/2008/09/01/260/ gcc4.1 implémente déjà tr1 shared_ptr.

En effet, et l'utilisation est très similaire à la mienne.
Seul truc qui me chagrine: j'ai comparé l'utilisation de la RAM et le temps d'exécution pour les deux codes suivants (sans le while true pour le temps):

Version avec shared_ptr
Code:

1 2 3 4 5 6 7 8 9 10 11 12 using std::tr1::shared_ptr; int main() { std::vector< shared_ptr<double> > vpt; for(unsigned long int i = 0; i < 10000000; ++i) vpt.push_back(shared_ptr<double>(new double((double)i / 3.14))); while(true); return 0; }
Ma version:
Code:

1 2 3 4 5 6 7 8 9 10 11 12 using std::tr1::shared_ptr; int main() { std::vector< smart_ptr<double> > vpt; for(unsigned long int i = 0; i < 10000000; ++i) vpt.push_back(smart_ptr<double>::make_ptr((double)i / 3.14)); while(true); return 0; }
J'obtiens une utilisation de respectivement 700Mo et 600Mo en RAM, et 5.524s et 3.664s en temps. Je consomme donc moins de mémoire avec mes smart_ptr tout en étant plus rapide, ce qui me donne envie de persévérer avec cette version.

A vue de nez, quelles seraient encore les failles à corriger d'après vous ?

23/03/2011, 14h59
JolyLoic

C'est vrai que dans TR1, il n'y a pas encore de make_shared, d'où une possibilité de baisse de performance non négligeable. Si tu peux avoir plus récent au final, ça vaut le coup de faire le test avec la différence. Sinon, shared_ptr gère la possibilité de weak_ptr, ainsi que le multithread, ce qui peut introduire des différences.

Donc avant de comparer les performances, il est intéressant de savoir de quelles fonctionnalités tu as besoin.

Si tu n'as besoin (même dans le futur) ni de multithread ni de weakptr, ni des autres choses fournies par shared_ptr et pas par smart_ptr (je n'ai pas vraiment lu ta classe, je ne peux pas dire), et que tu peux te permettre de maintenir cette classe, pourquoi pas continuer sur cette voie. Mais à ta place, je réfléchirai bien à ce que je veux avant de faire des benchs.
23/03/2011, 15h35
Caduchon

Globalement, quels sont les risques en multithread ?

Ca remonte à mes cours qui n'étaient que théoriques, et rien de tel que la pratique pour comprendre les thread il me semble... :mrgreen:

J'entrevois le risque de ne pas avoir delete un pointeur qui n'est pourtant plus référencé nulle part (une jolie fuite mémoire). Pour cela, il faudrait que les deux (ou plus) derniers smart_ptr se soient tous les deux dit "ce n'est pas mon rôle de supprimer ce pointeur" et qu'ils se soient supprimé sans deleter le pointeur interne.
Dans un destructeur, l'ordre des commandes est
1) décrémenter count
2) vérifier si count < 1
3) si c'est le cas, deleter le pointeur interne
4) quitter
Il faudrait donc que toutes les instances se terminent avec chacune un count >= 1. Je pense que dans ce cas ci, ce n'est pas possible.

Un autre problème pourrait être de delete un pointeur alors qu'il ne fallait pas (segmentation fault en vue...). Cela signifie qu'un processus vérifie que count < 1 à l'étape 2 et que count est remonté >= 1 lorsque ce processus se trouve à l'étape 3. Je crois que cela ne peut pas arriver non plus: En effet, si à un moment quelconque count < 1 cela signifie que toutes les instances existantes ont passé la phase de décrémentation et sont donc en phase terminale. Un delete pouvant être fait sur NULL ça ne pose pas de problème.

D'autres cas de figures sont problématiques ?
23/03/2011, 15h53
JolyLoic
Le code suivant :
Code:

1 2 3 4 f(smart_ptr s) { // fait quelque-chose avec s }
Si cette fonction est appelée deux fois en même temps il se peut que le compteur soit incrémenté une seule fois au lieu de deux, mais quand même décrémenté deux fois, et donc que l'on détruise un objet encore utilisé.
23/03/2011, 16h14
JolyLoic

Citation:

Envoyé par Caduchon

Un autre problème pourrait être de delete un pointeur alors qu'il ne fallait pas (segmentation fault en vue...). Cela signifie qu'un processus vérifie que count < 1 à l'étape 2 et que count est remonté >= 1 lorsque ce processus se trouve à l'étape 3. Je crois que cela ne peut pas arriver non plus: En effet, si à un moment quelconque count < 1 cela signifie que toutes les instances existantes ont passé la phase de décrémentation et sont donc en phase terminale. Un delete pouvant être fait sur NULL ça ne pose pas de problème.

C'est plus compliqué.

Si on a :
1 On décrémente (atomiquement, sinon c'est encore pire)
2 On vérifie si <1
3 On delete
4 on passe à NULL

On peut avoir pour 2 threads A et B alors que le compte est à 2 :
A1 (count =1) B1 (count = 0) A2 (vrai) B2(vrai) A3 B3 (boom, double delete) A4 B4

Sans compter qu'en présence de weak_ptr, un pointeur peut tenter de ressusciter par l'intermédiaire d'un weak au moment où le shared allait le détruire.
23/03/2011, 16h29
Caduchon
Citation:
Envoyé par JolyLoic

Le code suivant :

Code:

1 2 3 4 f(smart_ptr s) { // fait quelque-chose avec s }

Si cette fonction est appelée deux fois en même temps il se peut que le compteur soit incrémenté une seule fois au lieu de deux, mais quand même décrémenté deux fois, et donc que l'on détruise un objet encore utilisé.
Je ne comprend pas très bien pourquoi il ne serait incrémenté qu'une seule fois... :?

Citation:

Envoyé par JolyLoic

C'est plus compliqué.

Si on a :
1 On décrémente (atomiquement, sinon c'est encore pire)
2 On vérifie si <1
3 On delete
4 on passe à NULL

On peut avoir pour 2 threads A et B alors que le compte est à 2 :
A1 (count =1) B1 (count = 0) A2 (vrai) B2(vrai) A3 B3 (boom, double delete) A4 B4

Le problème d'un double delete serait un double appel au destructeur alors ?
Si je comprends bien, je dois placer un sémaphore avant le delete alors ? Et donc bouffer plein de mémoire (à moins de faire passer les informations par count (en valeurs négatives)...
23/03/2011, 16h45
JolyLoic

Citation:

Envoyé par Caduchon

Je ne comprend pas très bien pourquoi il ne serait incrémenté qu'une seule fois... :?

Il doit faire pour incrémenter une valeur :
1 Lire la valeur
2 Calculer l'incrémentation
3 Réécrire la valeur

Si on reprend les 2 threads A et B, rien n'empêche le scénario suivant (compte initial de 1) :
A1, A2, B1, B2, A3 (compte passe à 2), B3 (compte passe à 2).

Citation:
Envoyé par Caduchon
Suite à vos remarques, j'ai transformé mon code à plusieurs endroits.
J'ai supprimé ma classe make_ptr au profit de deux fonctions statiques, c'est nettement plus propre :mrgreen: :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 // Dans la classe: static smart_ptr<T> make_ptr(); static smart_ptr<T> make_ptr(const T& t); // Hors de la classe: template <class T> inline smart_ptr<T> smart_ptr<T>::make_ptr() { return smart_ptr<T>(new T); } template <class T> inline smart_ptr<T> smart_ptr<T>::make_ptr(const T& t) { return smart_ptr<T>(new T(t)); }
J'ai corrigé l'assignation:
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 template <class T> inline const smart_ptr<T>& smart_ptr<T>::operator = (const smart_ptr<T>& ptr) { if(p_ != ptr.p_) { --(*count_); if(*count_ == 0) { delete p_; delete count_; } p_ = ptr.p_; count_ = ptr.count_; ++(*count_); } return *this; }
Et j'ai renforcé la possibilité de gérer les exceptions:
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 template <class T> inline smart_ptr<T>::smart_ptr(T* ptr_t) : p_(ptr_t) { try { count_ = new unsigned long int(1); } catch(...) { delete p_; throw; } }
Je suis donc à l'écoute de vos autres remarques si vous en avez :)
NB: Je ne me suis pas encore questionné sur les const comme ça a été suggéré.
Ton opérateur d'affectation est toujours loin d'offrir les garanties d'exception suffisantes... cherche copy'n'swap idiome et no-throw swap.

23/03/2011, 17h32
Caduchon

Citation:

Envoyé par JolyLoic

Il doit faire pour incrémenter une valeur :
1 Lire la valeur
2 Calculer l'incrémentation
3 Réécrire la valeur

Si on reprend les 2 threads A et B, rien n'empêche le scénario suivant (compte initial de 1) :
A1, A2, B1, B2, A3 (compte passe à 2), B3 (compte passe à 2).

L'incrémentation n'est donc pas atomique ? :arf:
23/03/2011, 19h00
Goten

non