SmartPointer non fonctionnel

Citation:

---

Envoyé par Médinoc

Le problème, c'est que ce code suppose que dès que le pointeur est constant, les données pointées le sont aussi.
Si tu veux un smart pointer vers des données constantes, tu peux en faire un qui retourne toujours un T* et juste faire un CSmartPointer< const int > par exemple...

---

En effet je n'y ai pas pensé... Par exemple pour l'opérateur -> j'ai donc une seule fonction :

Code:

---

T * const operator -> () const;

---

Les premiers tests ont l'air de marcher, c'est correct?

Citation:

---

Envoyé par babar63

Je ne suis pas sûr de tout saisir (:oops:),

---

C'est simple (oublie les considérations théoriques sur l'exception safety); le code suivant ne doit pas causer de fuite de mémoire, quoi qu'il advienne :

Code:

---

CSmartPointer<T> p (new T);

---

Citation:

---

Envoyé par babar63

quelle serait le code adapté alors... :

Code:

---

1 2 3 4 5 6 7 8 9 10

CSmartPointer(T *_p) : p(_p) { try{ this->pr = new int(1); } catch(bad_alloc &) { delete p; throw; } }

---

,

---

Oui, mais pourquoi ne pas trouver attraper toutes les exceptions avec catch(...)?

Tu peux aussi utiliser une "function-try-block" :

Code:

---

1 2 3 4 5 6

CSmartPointer(T *p_) try : p(p_), pr(new int(1)) { } catch(...) { delete p_; }

---

La function-try-block d'un constructeur englobe l'initialisation des membres, il correspond à une portée extérieure. Il ne faut donc surtout pas se référer aux membres de l'objet dans le bloc catch :

• certains n'ont pas été construits parce qu'une exception a interrompu l'exécution de la liste d'initialisation,
• les autres ont été détruits avant d'entrer dans le bloc catch

Comme c'est un constructeur, atteindre la fin du bloc catch (le "}" fermant) relance l'exception (tout comme "throw;").

Citation:

---

Envoyé par babar63

Dans ce cas précis, la gestion d'un bloc catch_try ne coûte pas trop cher en terme de performance?

---

Sur une implémentation des exceptions à base de tables, le cout en temps d'exécution est nul. La taille de l'exécutable va très légèrement augmenter.

Citation:

---

Envoyé par babar63

En revanche le deuxième :

Code:

---

1 2 3 4

catch(std::bad_alloc &) { SAFE_DELETE(m_Pointer); throw; }

---

est correct non? Je l'utilise pour supprimer m_Pointer si il est NULL et le réinitialiser à NULL

---

Tu peux appeler delete sur un pointeur nul :

Code:

---

1 2	int *p = NULL; delete p;

---

Ce code est parfaitement valide (et inutile, évidemment).

(Mais je ne suis pas sûr si c'était le sens de ta question.)

Citation:

---

Envoyé par corrector

Oui, mais pourquoi ne pas trouver attraper toutes les exceptions avec catch(...)?

Tu peux aussi utiliser une "function-try-block"

---

Euh... sans doute parce que je ne connaissait pas tout ça :D, en tout cas merci c'est toujours bon à savoir.

Citation:

---

Ce code est parfaitement valide (et inutile, évidemment).

(Mais je ne suis pas sûr si c'était le sens de ta question.)

---

Si si, je viens de me relire c'était le sens de ma question, mais ce n'était pas voulu (:oops:) je voulais dire : "Je l'utilise pour supprimer m_Pointer si il est différent de NULL et le réinitialiser à NULL". Et puis au risque de ne toujours pas être clair voila la définition :

Code:

---

#define SAFE_DELETE(x) if(x) {delete x; x=0;}

---

NOTE : mon SAFE_DELETE ne serait pas très "safe" si il ne désallouait que les pointeurs NULL :mouarf:

NOTE2 : Encore une fois je tiens à remercier tout le monde pour les réponses apportées, ainsi que de m'avoir aidé à mieux comprendre tout ça! (surtout que je suis parfois à peine têtu) :merci:

Citation:

---

Envoyé par babar63

Si si, je viens de me relire c'était le sens de ma question, mais ce n'était pas voulu (:oops:) je voulais dire : "Je l'utilise pour supprimer m_Pointer si il est différent de NULL et le réinitialiser à NULL".

---

Oui, j'avais deviné!

Citation:

---

Envoyé par babar63

Et puis au risque de ne toujours pas être clair voila la définition :

Code:

---

#define SAFE_DELETE(x) if(x) {delete x; x=0;}

---

NOTE : mon SAFE_DELETE ne serait pas très "safe" si il ne désallouait que les pointeurs NULL :mouarf:

---

Pour ce qui est d'être "safe", que se passe t-il à ton avis avec ce code :

Code:

---

1 2 3 4

if (cond) SAFE_DELETE(p) else autre_chose();

---

et pour celui-la :

Code:

---

1 2 3 4

if (cond) SAFE_DELETE(p); else autre_chose();

---

Citation:

---

Envoyé par corrector

Pour ce qui est d'être "safe", que se passe t-il à ton avis avec ce code :

Code:

---

1 2 3 4

if (cond) SAFE_DELETE(p) else autre_chose();

---

et pour celui-la :

Code:

---

1 2 3 4

if (cond) SAFE_DELETE(p); else autre_chose();

---

---

Encore une erreur, je vais battre le record en un topic :roll:. Je suppose qu'UNE PARTIE du problème peut se résoudre comme ça :

Code:

---

#define SAFE_DELETE(x) { if(x) {delete x; x=0;} }

---

En revanche il reste toujours un problème mais je ne vois pas comment le régler :

Code:

---

1 2	if (cond) SAFE_DELETE(p); // Compile

---

Code:

---

1 2 3 4

if (cond) SAFE_DELETE(p); else // Erreur : "instruction else sans if correspondant non conforme" ...

---

Est-ce vraiment nécessaire de pouvoir compiler ce code sachant que :

Code:

---

1 2 3 4 5 6

if (cond) { SAFE_DELETE(p); } else // Ok ...

---

Et puis sachant aussi que le ";" est inutile?

EDIT : J'ai oublié, éventuellement une fonction inlinée pourrais remplacé le define, mais est-ce vraiment utile... ?

Citation:

---

Envoyé par babar63

EDIT : J'ai oublié, éventuellement une fonction inlinée pourrais remplacé le define, mais est-ce vraiment utile... ?

---

C'est là où je voulais en venir : pourquoi s'embêter avec les macros et les problèmes associés, dont tu as eu un aperçu, alors que tu peux écrire une vraie fonction normale, inline pour éviter tout surcout. (Mais, par rapport à delete, un appel de fonction n'est pas bien lourd.)

Citation:

---

Envoyé par corrector

pourquoi s'embêter avec les macros et les problèmes associés

---

Dans ce cas précis, quelles sont les problèmes associés que l'ont n'aurait pas avec une fonction, exemple :

Code:

---

1 2 3 4 5

if (cond) SAFE_DELETE(p); else // Macro : Erreur // Fonction : Ok ...

---

et :

Code:

---

1 2 3 4 5

if (cond) SAFE_DELETE(p) else // Macro : Ok // Fonction : Erreur ...

---

Mis à part le fait que les macros "semblent" être de moins en mois appréciées quand elle peuvent être évitées (enfin je dis ça d'après ce que j'en ai lu..), dans ce cas c'est bien une question de choix non?

Citation:

---

Envoyé par babar63

Dans ce cas précis, quelles sont les problèmes associés que l'ont n'aurait pas avec une fonction, exemple :

---

Ce que j'ai montré précédemment, déjà. (Il y en d'autres, essaie de les trouver.)

Citation:

---

Envoyé par babar63

Mis à part le fait que les macros "semblent" être de moins en mois appréciées quand elle peuvent être évitées (enfin je dis ça d'après ce que j'en ai lu..)

---

Ce n'est pas que les macros sont de moins en moins appréciées, elles sont détestées (en plus, le préprocesseur est un très mauvais langage de macro : peu puissant, difficile à définir et à implémenter, en plus il est mal intégré au langage).

On les utilise quand on n'a pas mieux.

Quand une fonction fait l'affaire, utiliser une macro est considéré comme une erreur grossière.

Citation:

---

Envoyé par babar63

Je ne suis pas encore bien habitué au mot clé explicit mais dans mon projet j'utilise :

Code:

---

SceneManager.AddCamera( new CCamera(*this) );

---

Avec AddCamera prenant un smart pointer (de CCamera) en paramètre, dans ce cas il faut bien utiliser le constructeur en tant que conversion implicite non?

---

Oui, c'est bien l'usage d'un constructeur de conversion ("converting constructor") :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

class A { public: explicit A (int); A (const char*); // non-explicit };   void foo (A);   int main() { foo (1); // erreur foo ("1"); // OK, équivaut à : foo (A("1"));   A a = 2; // erreur A a = "2"; // OK, équivaut à : A a = A("2"); }

---

Citation:

---

Envoyé par babar63

Pourquoi cette question revient-elle?

---

Comme il n'y a pas de mot-clef "implicit", l'absence d'explicit sur un constructeur à un argument peut être un simple oublie, sans un commentaire comment savoir.

Citation:

---

Envoyé par Médinoc

Il y a des risques (dans mon cas)?

---

Le risque de la conversion implicite, c'est qu'elle est implicite (n'est-ce pas), alors tu peux l'invoquer par erreur, et, par exemple, donner à un smart pointer la propriété d'un pointeur, sans le vouloir.

La crainte avec les conversions implicites c'est de les faire sans le vouloir, et qu'un code incorrect compile grâce à elles. En pratique, il faut analyser l'opportunité de déclarer des conversions implicites au cas par cas.

Citation:

---

Envoyé par Médinoc

J'ai surtout posé la question par mimétisme, parce que corrector la posait...

---

Ouha... quelle influence j'ai!

Citation:

---

Envoyé par babar63

Encore une erreur, je vais battre le record en un topic :roll:. Je suppose qu'UNE PARTIE du problème peut se résoudre comme ça :

Code:

---

#define SAFE_DELETE(x) { if(x) {delete x; x=0;} }

---

En revanche il reste toujours un problème mais je ne vois pas comment le régler :

Code:

---

1 2	if (cond) SAFE_DELETE(p); // Compile

---

Code:

---

1 2 3 4

if (cond) SAFE_DELETE(p); else // Erreur : "instruction else sans if correspondant non conforme" ...

---

---

Essaie:

Code:

---

1 2	#define SAFE_DELETE(p) do { if(x) { delete (x); (x)=0; } } while (false)

---

Qui devrait résoudre les problèmes de 'if' imbriqués et le problème du ';'.

Ceci dit, la meilleure manière de le faire reste:

Code:

---

1 2 3 4 5 6 7

namespace { template <class T> void safe_delete(T*& p) { if (p) { delete p; p = NULL; } } }

---

Autre chose, cette fonction n'est pas un safe_delete mais un delete_to_null. Rien à voir (au niveau du nom et de la fonction réalisée).

Citation:

---

Envoyé par Emmanuel Deloget

Essaie:

Code:

---

1 2	#define SAFE_DELETE(p) do { if(x) { delete (x); (x)=0; } } while (false)

---

Qui devrait résoudre les problèmes de 'if' imbriqués et le problème du ';'.

Ceci dit, la meilleure manière de le faire reste:

Code:

---

1 2 3 4 5 6 7

namespace { template <class T> void safe_delete(T*& p) { if (p) { delete p; p = NULL; } } }

---

Autre chose, cette fonction n'est pas un safe_delete mais un delete_to_null. Rien à voir (au niveau du nom et de la fonction réalisée).

---

Merci pour ces précisions, comme conseillé par corrector, j'ai déjà créé une fonction :

Code:

---

1 2 3 4 5 6 7 8 9

template <class T> inline void SafeDelete(T *ptr) { if(ptr!=0) { delete ptr; ptr=0; } }

---

J'aurais quand même une ou deux questions par rapport à ton code, pourquoi utiliser un namespace sans nom? Cela change-t-il quelques choses? Aussi je ne vois pas la différence entre "T *&" et "T *"... :aie: ?

Citation:

---

Aussi je ne vois pas la différence entre "T *&" et "T *"... ?

---

C'est simple: Sans le &, ton ptr=0 ne sert à rien.

Citation:

---

Envoyé par babar63

Merci pour ces précisions, comme conseillé par corrector, j'ai déjà créé une fonction :

Code:

---

1 2 3 4 5 6 7 8 9

template <class T> inline void SafeDelete(T *ptr) { if(ptr!=0) { delete ptr; ptr=0; } }

---

J'aurais quand même une ou deux questions par rapport à ton code, pourquoi utiliser un namespace sans nom? Cela change-t-il quelques choses? Aussi je ne vois pas la différence entre "T *&" et "T *"... :aie: ?

---

Quand au namespace anonyme, il est équivalent à créer une fonction statique (c'est à dire locale à l'unité de compilation). Ce n'est pas nécessaire, mais ça peut quand même être utile.

Citation:

---

Envoyé par Médinoc

C'est simple: Sans le &, ton ptr=0 ne sert à rien.

---

En effet ça a du sens, merci pour la précision :D

Citation:

---

Envoyé par Emmanuel Deloget

Quand au namespace anonyme, il est équivalent à créer une fonction statique (c'est à dire locale à l'unité de compilation). Ce n'est pas nécessaire, mais ça peut quand même être utile.

---

Donc si j'ai bien compris, dans mon cas c'est à éviter, puisque je souhaite pouvoir réutiliser cette fonction dans d'autre projets(/fichiers).

Citation:

---

Autre chose, cette fonction n'est pas un safe_delete mais un delete_to_null. Rien à voir (au niveau du nom et de la fonction réalisée).

---

Et je vais aussi la renommer :mouarf:, à la base j'ai donné ce nom car j'ai vu cette fonction(Macro) plusieurs fois sous ce nom (:oops:) mais en effet il ne semble pas y avoir de bonnes raisons (enfin à ma connaissance)...

Encore merci à tous pour tous ces précieux conseils :D