Différence Pointeur Référence.

screetch · 26/11/2010, 13h02

Envoyé par gl

Je ne vois pas en quoi l'utilisation d'une référence ne devrait pas être utilisée pour une classe à sémantique d'entité.
Une référence ne copie/crée pas un objet mais crée un alias sur un objet, au final c'est, dans l'esprit, un comportement assez proche de l'utilisation d'un pointeur modulo la non nullité, la constance, etc.

Déjà je dois dire que je n'utilise pas de pointeurs nus (en tous cas le moins possible) au profit des pointeurs intelligents
Et dans ce cas j'ai surtout entité = pointeur intelligent, valeur = référence
car une référence ne convoie pas l'information sur la durée de vie d'un objet (tout comme un pointeur nu)
c'est comme ca que je l'utilise et si tu poses la question comme ca, j'avoue pouvoir la retourner et demander: quel gain a utiliser une référence dans ce cas? (par rapport a un pointeur nu). Mis a part la non nullité.

**koala01** · 26/11/2010, 13h06

Envoyé par Astraya

Autant pour moi

Bah, il n'y a pas de mal...

(HS pour présenter ses excuses, c'est "au temps pour moi" car, quand on écrit "autant pour moi", c'est qu'on souhaite... la même quantité de quelque chose que la personne qui a parlé juste avant "bonjour, je voudrais cinq kilo de patates", et le client suivant "bonjour, autant pour moi"

)

screetch · 26/11/2010, 13h10

(HS Autant pour moi serait une forme elliptique de C’est autant pour moi, sous-entendu C’est autant d’erreur que l’on peut mettre à mon actif.)

**Goten** · 26/11/2010, 13h12

Envoyé par koala01

Bah, il n'y a pas de mal...

(HS pour présenter ses excuses, c'est "au temps pour moi" car, quand on écrit "autant pour moi", c'est qu'on souhaite... la même quantité de quelque chose que la personne qui a parlé juste avant "bonjour, je voudrais cinq kilo de patates", et le client suivant "bonjour, autant pour moi"

)

(HS : ça finira donc jamais ce débat ?

Les deux sont valides.)

**Astraya** · 26/11/2010, 13h16

Bah, il n'y a pas de mal...

(HS pour présenter ses excuses, c'est "au temps pour moi" car, quand on écrit "autant pour moi", c'est qu'on souhaite... la même quantité de quelque chose que la personne qui a parlé juste avant "bonjour, je voudrais cinq kilo de patates", et le client suivant "bonjour, autant pour moi"

)

(HS : Apparement "au temps" est d'origine militaire. Selon le Robert c'est " au temps". Selon les américains c'est "My bad."

. Y aurait-il des hommes de lettres parmi nous?

)

screetch · 26/11/2010, 13h32

(HS et j'espere le dernier: les deux sont admis, avec une préférence pour ce qui serait l'original: au temps pour moi. Mais autant pour moi est aussi correct)

**Emmanuel Deloget** · 26/11/2010, 14h11

(tiens ? je me suis logué sur sementiquez.net ?)

Sur le sujet des pointeurs intelligents : il y a une confusion étrange sur le fait qu'il soient utiles, même en C++ (pas d'offense, screetch, hein ?

). Un pointeur intelligent gère la durée de vie d'une instance à la place du programmeur.

Plusieurs raisons peuvent pousser à l'adoption de smart pointers:

1) la flemme : le programmeur n'a pas envie de gérer lui même la durée de vie de son instance. Je comprends tout à fait que la flemme soit à la base même de notre métier, mais il y a peut-être des limites à ne pas dépasser

En tout cas, ce n'est pas une bonne raison.

2) le programmeur n'a pas pris la peine de designer correctement son application, et il n'a pas pu déterminer la durée de vie de l'instance : c'est une erreur de sa part, qu'il cache par une sur-utilisation des pointeurs intelligents. C'est mauvais, très mauvais.

3) le programmeur n'a aucun moyen de déterminer la durée de vie de l'instance : je n'ai jamais rencontré ce cas, mais je veux bien croire qu'il existe. Avec un bémol toutefois : un programme est censé être prédictif, et par conséquent, démontrable. Dans ce cadre, je ne vois pas bien par quel étrange phénomène le comportement de l'instance deviendrait non prédictif.

4) le programmeur ne sait pas qui possède l'instance : l'instance est partagée par plusieurs objets, et le programmeur n'a pas défini celui qui en était responsable. Pour pallier à ce défaut, on permet à chacun des objets de détruire l'instance en question dès lors qu'il détecte qu'elle n'est plus utilisée. C'est bancal au mieux, catastrophique (au niveau design) au pire.

5) la possession évolue : la possession est passée à un objet, puis à un autre, etc. Afin de ne pas avoir à tracer cette possession, on utilise un pointeur intelligent. C'est à la limite de la fainéantise exagérée.

Les smart pointers donne une mauvaise réponse sous la forme de code à une question de pur design. Dans mon optique, il sont au mieux dangereux, et doivent être utilisés avec la plus extrême parcimonie. Les notions de durée de vie et de possession sont deux notions centrales en conception OO, et laisser un morceau de code décider de leur existence à la place de l'architecte, c'est aller droit dans le mur en accélérant un peu plus à chaque mètre parcouru. Je ne connais pas une seule utilisation correcte de cet outil. C'est le goto du 21ème siècle.

Au final, je trouve que les pointeurs intelligents sont nettement bêtes

(et je suis effaré de me rendre compte que je suis le seul à penser ça. Ouch.).

**Médinoc** · 26/11/2010, 14h43

^Y compris les scoped_ptr? C'est le b-a-ba de la RAII!

screetch · 26/11/2010, 14h50

j'avoue ne pas les utiliser comme cela.
et j'avoue ne pas utiliser les pointeurs de boost/stl parce que je suis un peu d'accord avec toi.
j'ai trois types de pointeurs:
* scoped: un seul propriétaire
* refcounté: plusieurs propriétaires
* weak: je ne suis pas le propriétaire
(j'en ai d'autres mais ils sont beaucoup plus spécifiques)

a partir de refcounté et de scoped il est possible d'obtenir des weak
a partir des weak, il n'est pas permis de réobtenir un scoped/redcounté, donc de demander la propriété (même partagée) d'une entité.
De plus, le weak n'est pas le weak au sens boost; le weak est, si jamais l'objet pointé meurt, le weak emet une assertion. On ne peut pas référencer un objet mort, même si on ne va pas l'utiliser.

la facon dont je l'utilise, c'est que les refptr/scoped sont utilisés comme stockage, et les variables intermédiares sont des weak.
par exemple, une interface devrait le plus souvent possible renvoyer un weak. Ainsi, on sait que l'appelant n'est jamais le propriétaire de l'entité.

Cela a alors l'effet inverse de ce que tu dis; la propriété est "clairement" établie dans le code et on peut meme interdire de la propager. Cela force les gens a se poser la question de la durée de vie (du moins je l'espère, puisque c'est mon but).
Je voudrais juste utiliser scoped plus souvent

Et depuis que je développe sur mon projet j'utilise le detecteur de leak de visual studio, et il n'a rien reporté depuis plus de 2 ans, ce que je trouve est pas si mal (meme si le developpement est pas super rapide non plus).

Mais je suis globalement d'accord avec toi, mais je remplace "pointeurs intelligent" par "garbage collector" dans ton post!

**Médinoc** · 26/11/2010, 14h58

Les auto_ptr de la STL ont aussi leur utilité, vu qu'ils donnent droit à la fois à la sémantique de transfert et à la RAII.
Leur inconvénient est leur incompatibilité dangereuse avec l'opérateur = (mais on peut espérer que cela soit corrigé dans C++1x, vu que la classe n'aura plus à simuler les rvalue references).

Aussi, les pointeurs refcountés ont leur utilité dans le copy-on-write, où l'on ne veut PAS qu'il y ait un propriétaire en particulier.

**Emmanuel Deloget** · 26/11/2010, 15h01

Envoyé par Médinoc

Y compris les scoped_ptr? C'est le b-a-ba de la RAII!

C'est marqué dans le nom : scoped_ptr. Ce qui implique une notion de durée de vie connue, et de propriété (parce que le scoped_ptr ne peut être possédé que par un seul objet). C'est un auto_ptr amélioré, qui n'a pas (à ma connaissance) de compte de références associé. Bref : ce n'est pas un pointeur intelligent, c'est un pointeur encapsulé

Dans 9 cas sur 10 dans le code existant, le scoped_ptr peut être remplacé par autre chose - genre une variable automatique qui aura la même durée de vie.

**Médinoc** · 26/11/2010, 15h31

Et la raison pour laquelle on ne fait pas le remplacement, c'est avoir du code exception-safe. Pourquoi s'en priver?

**Klaim** · 26/11/2010, 15h32

En fait, souvent les smart pointers sont là pour qu'un autre développeur qui ne comprends pas immédiatemnet comment utiliser un pointeur qu'on lui fourni ne fasse pas une betise avec, comme un delete. (la propriété donc);

Du coup c'est plus pour une question de communication (accessoirement appliquée par le language) que réellement pour manager la durée de vie (même si on le fait systématiquement à chaque implémentation).

screetch · 26/11/2010, 15h50

Envoyé par Médinoc

Et la raison pour laquelle on ne fait pas le remplacement, c'est avoir du code exception-safe. Pourquoi s'en priver?

Emmanuel disait que

Code :

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

auto<A> a = new A;

et

Code :

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

A a;

sont interchangeables. Dans le deuxieme cas, c'est toujours exception-safe.

screetch · 26/11/2010, 15h51

Envoyé par Klaim

En fait, souvent les smart pointers sont là pour qu'un autre développeur qui ne comprends pas immédiatemnet comment utiliser un pointeur qu'on lui fourni ne fasse pas une betise avec, comme un delete. (la propriété donc);

Du coup c'est plus pour une question de communication (accessoirement appliquée par le language) que réellement pour manager la durée de vie (même si on le fait systématiquement à chaque implémentation).

un autre développeur n'a aucun moyen de savoir ce qu'il doit faire avec un pointeur. Certaines methodes sont des factory et donnent a l'appelant la responsabilité, certaines methodes renvoient un pointeur que l'on ne doit pas supprimer. Comment faire la différence?

**Médinoc** · 26/11/2010, 16h19

Envoyé par screetch

Emmanuel disait que

Code :

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

auto<A> a = new A;

et

Code :

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

A a;

sont interchangeables. Dans le deuxieme cas, c'est toujours exception-safe.

Mais pas en retour de fonction.

Et pas en instanciation conditionnelle:

Code C++ :

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

1
2
3
4
5
6
7
8
9
{
	auto_ptr<A> a;
	if( ... )
		a.reset(new A( X, Y ));
	else
		a.reset(new A( Z ));
 
	a->DoSomething();
}

Note: dans le cas présenter ici, je considère que dupliquer DoSomething() (qui peut être plusieurs appels, interactions avec autres objets, etc.) n'est pas préférable à utiliser un pointeur intelligent.

**Goten** · 26/11/2010, 16h33

Envoyé par Emmanuel Deloget

C'est marqué dans le nom : scoped_ptr. Ce qui implique une notion de durée de vie connue, et de propriété (parce que le scoped_ptr ne peut être possédé que par un seul objet). C'est un auto_ptr amélioré, qui n'a pas (à ma connaissance) de compte de références associé. Bref : ce n'est pas un pointeur intelligent, c'est un pointeur encapsulé

Dans 9 cas sur 10 dans le code existant, le scoped_ptr peut être remplacé par autre chose - genre une variable automatique qui aura la même durée de vie.

Et se privée de l'exception safety? L'avantage des poineurs c'est que les opérations sont garanties no-throw...

**Emmanuel Deloget** · 26/11/2010, 16h57

Envoyé par Goten

Et se privée de l'exception safety? L'avantage des poineurs c'est que les opérations sont garanties no-throw...

Meh ?

Si le but est juste de stocker un pointeur et pas de l'utiliser d'une manière ou d'une autre, en quoi l'utilisation d'un scoped_ptr a-t-elle un intérêt ? Il faut bien qu'à un moment donné l'instance soit crées (pas de garantie no-throw) ou que les méthodes de cette instance soient appelées (idem). Si on ne fait que manipuler le pointeur et effectuer des opérations sur lui, alors i n'y a pas besoin de l'encapsuler dans quoi que ce soit.

Je vois pas ce que la résistance aux exception viens faire dans ce cas (et de toute façon, j'en reste là : 9 fois sur 10, le scoped_ptr n'est pas utilisé pour ses qualités intrinsèques).

screetch · 26/11/2010, 17h01

je suis comme emmanuel, je comprends mal ce que vous reprocher a utiliser l'objet lui meme plutot qu'un autoptr dessus?

**Emmanuel Deloget** · 26/11/2010, 17h13

Envoyé par Médinoc

Et pas en instanciation conditionnelle:

Code C++ :

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

1
2
3
4
5
6
7
8
9
{
	auto_ptr<A> a;
	if( ... )
		a.reset(new A( X, Y ));
	else
		a.reset(new A( Z ));
 
	a->DoSomething();
}

Effectivement - ca représente une bonne partie du 1/10 restant. Il y a aussi le cas inverse, qui est tout aussi intéressant.

Code :

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

1
2
3
4
5
6
7
8
9
10
 
X* f()
{
  auto_ptr<X> p(new X);
 
  if (cond1(p)) return NULL; // détruit l'instance automatiquement
  if (cond2(p)) return NULL; // détruit l'instance automatiquement
 
  return p.release(); // libère le pointeur, ce qui permet de ne pas détruire l'instance.
}

Je n'ai pas le courage de faire une recherche de code dans google code, codeplex ou sf.net pour démontrer ce que je dis, mais j'en suis pas mal persuadé : trop souvent, les scoped_ptr ne sont pas utilisés à bon escient. Il sont utiles, c'est vrai - contrairement aux smart pointers - mais bien moins que prévu.

Différence Pointeur Référence.

C++

Discussions similaires

Partager

Partager