Sondage test d'un pointeur.

Comment tester vous un pointeur avant de vous en servir?

Code:

---

1 2 3 4 5 6

void testPtr() { int A = 1; int*pA = &A; return pA && (*pA)==1; }

---

Code:

---

1 2 3 4 5 6 7 8 9 10 11

void testPtr() { int A = 1; int*pA = &A; bool bResult = false; if (0 != pA) { bResult = (*pA)==1; } return bResult; }

---

Les deux code sont valide et on le même comportement d'après ce que j'ai pu lire sur le site http://www.cppreference.com/wiki/fr/operator_precedence.

Seconde question:
Que pensez vous de chaîner des appel de fonction (qui retourne juste un bool) via l'opérateur '&&' ?

NB: Le compilateur que j'utilise ne gère pas les smart pointer shared_ptr.

Bonjour,

pour ma part je fais comme ceci

Code:

---

1 2 3 4

int* pA = NULL; // toujours initialiser à NULL if (pA) // on peut aussi être plus explicite if(pA != NULL) (mais je crois que la première écriture est plus favorisée/souhaitée) #define SafeDelete(ptr) if(ptr) delete ptr; ptr = NULL; // une macro pour delete mes pointeurs tranquillement SafeDelete(pA);

---

Quant au chaining avec &&, il ne me choque/gène pas.

Pour ma part, c'est std::unique_ptr (ou shared_ptr/weak_ptr, ou auto_ptr si on est vraiment obligé d'en rester à du pré-c++11).

Je dirais plutôt :

Code:

---

1 2 3 4 5

if (pA) { //... }

---

Je pense qu'il est préférable d'éviter toute référence à 0 ou NULL dans du nouveau code afin de préparer le passage à nullptr.

Citation:

---

Envoyé par Niark13

Je dirais plutôt :

Code:

---

1 2 3 4 5

if (pA) { //... }

---

Je pense qu'il est préférable d'éviter toute référence à 0 ou NULL dans du nouveau code afin de préparer le passage à nullptr.

---

Certe mais ma question porte sur la tendance à tester dans un if le pointeur avant de l'utiliser dans le core du if ou de tester et utiliser avec l'opérande '&&'.

Code:

---

#define SafeDelete(ptr) if(ptr) delete ptr; ptr = NULL;

---

ce code est inutile, car delete NULL ne fait rien du tout, donc pas besoin de tester si le pointeur est nul avant de le détruire.

Salut,

Citation:

---

Envoyé par Kalite

Comment testez-vous un pointeur avant de vous en servir?

---

J'utilise au maximum des références dès que le pointeur n'a pas à être NULL dans le code.
Sinon, ensuite c'est la lisibilité qui va surtout jouer. Dans ton exemple (un return ou une affectation par expl), un simple return ptr?0:1; ou return (NULL==ptr)?0:1; suffit. Pour un comportement moins trivial,

Code:

---

1 2 3 4

if(ptr) {...} else {...}

---

Citation:

---

Envoyé par Kalite

Seconde question:
Que pensez vous de chaîner des appel de fonction (qui retourne juste un bool) via l'opérateur '&&' ?

---

J'ai horreur des lignes de code de type :

Code:

---

1 2	if( c1 && c2 && c3 && c4 ...)

---

On ne comprend jamais clairement l'objectif du test. Je préfère largement :

Code:

---

1 2 3 4

if(IsSomethingTrue()) {} ....

---

Citation:

---

Envoyé par Kalite

NB: Le compilateur que j'utilise ne gère pas les smart pointer shared_ptr.

---

Si ton compilateur permet pour une classe de créer un constructeur, un constructeur de copie, un opérateur d'affectation et un destructeur, alors tu n'as strictement aucune raison de gérer un pointeur nu. Un smart pointeur ce n'est rien de plus qu'une enveloppe RAII.

Hors sujet:

Citation:

---

Envoyé par 3DArchi

Si ton compilateur permet pour une classe de créer un constructeur, un constructeur de copie, un opérateur d'affectation et un destructeur, alors tu n'as strictement aucune raison de gérer un pointeur nu. Un smart pointeur ce n'est rien de plus qu'une enveloppe RAII.

---

Je disais ça pour ceux qui me dirai : "Utilise les smart pointeur !"
Le compilateur que j'utilise est c++ builder 5.02, donc autant te dire que j'ai pas du tout la STL. De plus, j'ai clairement pas envie de réinventé la roue carré. Je préfère attendre le passage à un compilateur avec STL.

Citation:

---

Envoyé par Kalite

Hors sujet:

Je disais ça pour ceux qui me dirai : "Utilise les smart pointeur !"

---

Oops, j'aurais dû lire jusqu'au bout. Désolé !

Citation:

---

Le compilateur que j'utilise est c++ builder 5.02, donc autant te dire que j'ai pas du tout la STL. De plus, j'ai clairement pas envie de réinventé la roue carré. Je préfère attendre le passage à un compilateur avec STL.

---

Il reste quand même sûrement boost::shared_ptr. Après, il faudrait quand même vérifier qu'il fonctionne sous ce compilateur.

Au passage, il y a des projets comme STLPort qui est disponible gratuitement et qui fournit la STL sous de nombreux compilateurs. ;)

Citation:

---

Envoyé par Kalite

De plus, j'ai clairement pas envie de réinventé la roue carré.

---

Tu peux au - rajouter une enveloppe RAII à minima qui interdit la copie (à la volée):

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

template<class T> struct scopped_ptr { public: explicit scopped_ptr(T*p_):p(p_) {} ~scopped_ptr() { delete p; } T const & operator*() const {return *p;} T& operator*(){return *p;}   T const * operator->() const {return p;} T* operator->(){return p;}   private: scopped_ptr(scopped_ptr const&); scopped_ptr&operator=(scopped_ptr const&);   T*p; };

---

Tu te protèges contre les exceptions, les copies 'cachées' et les fuites mémoires.

Loïc, dans son article sur les pointeurs intelligents, fait un exercice similaire avec une politique de copie profonde.

Et, tu peux rendre non copiable tes classes ayant des ressources en propre

Effectivement sa serait bien mais bon je change de compilateur d'ici la fin du mois. Donc j'ai pas trop d’intérêt a le faire. Mais je conserve l'idée car on ne sais jamais si je retombe sur un vieux compilateur sans STL.

Citation:

---

Envoyé par Kalite

Certe mais ma question porte sur la tendance à tester dans un if le pointeur avant de l'utiliser dans le core du if ou de tester et utiliser avec l'opérande '&&'.

---

Ok. J'ai tendance à trouver que

Code:

---

if (condition) { A; } else { B; }

---

est beaucoup beaucoup plus lisible que

Code:

---

(condition) && (A) || (B);

---

qu'il soit question de pointeur ou pas dans le test ! :aie: