Discussion :

[Kalite]

Comment tester vous un pointeur avant de vous en servir?

Code :

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

1
2
3
4
5
6
void testPtr()
{
  int A = 1;
  int*pA = &A;
  return pA && (*pA)==1;
}

Code :

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

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.

[Bousk]

Bonjour,

pour ma part je fais comme ceci

Code :

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

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.

[Ekleog]

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).

[Niark13]

Je dirais plutôt :

Code :

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

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.

[Kalite]

Je dirais plutôt :

Code :

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

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 '&&'.

[dragonjoker59]

Code :

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

#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.

[3DArchi]

Salut,

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 :

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

1
2
3
4
if(ptr)
{...}
else
{...}

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 :

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

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

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

Code :

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

1
2
3
4
 
if(IsSomethingTrue())
{}
....

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.

[Kalite]

Hors sujet:

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.

[Ekleog]

Hors sujet:

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

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

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.

[3DArchi]

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 :

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
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

[Kalite]

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.

[Niark13]

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 :

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

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

est beaucoup beaucoup plus lisible que

Code :

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

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

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