Discussion :

[r0d]

Bonjour,

je suis tombé par pseudo-hasard sur cette page:
http://en.cppreference.com/w/cpp/exp...l/observer_ptr

Il s'agit d'un pointeur intelligent qui ne possède pas l'objet pointé.
Autrement dit, c'est un pointeur intelligent qui ne fait rien, ni lors de l'assignation (pas de compteur), ni en fin de vie (il ne touche pas à l'objet pointé).
Autrement dit, ce n'est finalement rien d'autre qu'un pointeur nu renommé.
Autrement dit, on pourrait proposer une implémentation de observer_ptr comme suit:

Code :

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

1
2
template<typename T>
using observer_ptr = T*;

Du coup, ça me ramène à une de mes vieilles interrogations: l'utilisation de pointeurs nus est-elle si diabolique qu'on le dit?
Moi personnellement, j'utilise des pointeurs nus dans mes programmes, mais en respectant la règle d'or suivante: jamais, Ô grand jamais, de delete (donc pas de "new nu", j'y reviendrai). Autrement dit, je m'octroie le droit d'utiliser des pointeurs nus, à condition que ceux-ci ne soient jamais propriétaires des objets pointés. Avec pour conséquence assumée (et parfois souhaitée) que ce pointeur puisse être null. Et jusqu'ici, sauf dans d'improbables cas de terrorisme orienté objet (par exemple utiliser un pointeur déclaré statique et initialisé sur une référence), mes programmes sont très stables.

Au final, je me demande donc si la polémique du pointeur nu ne serait pas un faux problème. A l'instar du RAII qui est mal nommé, le problème du pointeur n'est pas sa création, mais sa destruction. Mais sa création (construction) détermine sa destruction. Si on créée un pointeur avec un "new nu", c'est à dire un new en dehors de toute forme d'encapsulation (notamment dans un smart pointer), alors il faudra faire un delete. Si en revanche on utilise un new encapsulé dans une structure raii-esque (de type smart pointer notamment), alors on a pas besoin de delete et alors tout va bien, puisque le cycle de vie sera géré de façon simple et intelligente par la structure en question.

Et donc, et pour finir, j'en arrive à me demander quelle peut bien être l'utilité de cet étrange animal, l'observer_ptr.

[renoo]

Il m'arrive aussi d'utiliser parfois des pointeurs nus non responsable de la vie d'un objet : la limite principale c'est que si l'objet est détruit alors on risque d'obtenir un comportement indéfini et ça c'est mal car ça peut faire n'importe quoi et cela peut etre difficile à trouver et corriger.

[jo_link_noir]

À mon sens, le problème n'est pas le pointeur, mais l'intention que véhicule le pointeur: plein de questions sans réponses.
- Ressource managée ? Qui est propriétaire ? Comment libérer ?
- Pointeur pouvant être nul ?
- Tableau ou simple valeur ? Bon ok, on donne une taille si c'est un tableau.

En mettant observer_ptr, on répond au moins aux 2 premières questions.
Par contre, je crois que delete observer_ptr; compile quand même. Dommage, l'opérateur aurait pu être supprimé,

[Invité]

@r0d : j'utilise parfois des pointeurs nus de la même façon que toi. Du coup, l'apparition de ce observer_ptr est plutôt une bonne nouvelle : d'une part çà met un nom sur cet usage des pointeurs (+ les vérifications qui vont bien) et d'autre part çà semble indiquer que cet usage n'est pas complètement idiot.

@jo_link_noir :
- avec les array et vector, je ne vois plus vraiment de raison d'utiliser des pointeurs pour les tableaux, même si c'est effectivement encore autorisé
- pour le delete, je ne suis pas sûr de te comprendre; le code delete observer; signifie que tu as créé un observer_ptr dynamiquement (avec un new), ce qui est un peu tordu. Ne voudrais tu pas dire plutôt delete observer.get(); ? Et dans ce cas c'est effectivement dommage si çà compile.

[Aurelien.Regat-Barrel]

Tu as la réponse à ces questions dans les C++ core guidelines:
https://github.com/isocpp/CppCoreGui....md#S-resource

c'est bien une question de gestion de propriété des ressources. Mais observer_ptr est à priori une mauvaise idée, car il n'apporte rien par rapport à un pointeur brut. Ou dit autrement : l'usage recommandé du pointeur brut est en tant que observer_ptr. Et donc, devoir spécifier à chaque fois le terme "observer_ptr" pour un comportement par défaut est un mauvais design.

En revanche, ses petits copains du même type : owner<T*>, not_null<T*> apportent une réelle plus-value. L'intérêt de les déclarer sous forme de simple alias (avec using) au lieu d'être des wrappers fait qu'ils n'ont aucun impact à l'édition des liens (pas de modification du name mangling et donc de l'ABI).

Alors oui le compilo ne peut pas vérifier le respect de la convention d'usage, mais un outil d'analyse statique de code oui. Et d'ailleurs, il y en a un qui est censé arriver bientôt, en open source. Tout est expliqué ici :

[Invité]

c'est bien une question de gestion de propriété des ressources. Mais observer_ptr est à priori une mauvaise idée, car il n'apporte rien par rapport à un pointeur brut. Ou dit autrement : l'usage recommandé du pointeur brut est en tant que observer_ptr. Et donc, devoir spécifier à chaque fois le terme "observer_ptr" pour un comportement par défaut est un mauvais design.

Pas forcément. Le pointeur brut correspond à la fonctionnalité bas-niveau. La guideline R.3 suggère effectivement de l'utiliser comme observer parce que c'est le comportement par défaut mais rien n'oblige à l'utiliser ainsi. Du coup, cet observer_ptr permet de clarifier les choses et rend cette guideline inutile.

@jo_link_noir : exact, je n'avais pas vu le cast. Et effectivement avec le "explicit", il faut quand même sacrément en vouloir pour faire le vilain delete.

[jo_link_noir]

@nokomprendo: Plutôt dans la situation où on "oublie" que ptr n'est qu'un observable. Vu qu'observer_ptr possède un cast vers T*, delete pourrait fonctionner. Sauf qu'hier, je n'avais pas vu que le cast était explicite .