dans Scott Meyers efficace C ++ i>, élément 18 Faire des interfaces faciles à utiliser correctement et difficiles à utiliser de manière incorrecte i>, il a mentionné le null Shared_ptr: et une opération d'affectation de vogue p> auquel cas on peut nécessiter de créer un null Shared_ptr et faire une affectation plus tard? Pourquoi ne pas simplement créer le Shared_ptr chaque fois que vous avez les ressources (pointeur brut)? P> Étant donné que Scott Meyers n'a pas montré l'affectation complète dans l'exemple précédent, je pensais que l'opérateur d'affectation de Shared_Ptr est surchargé que l'on peut le faire. : P> sptr.cpp: In function ‘int main(int, char**)’:
sptr.cpp:8:39: error: conversion from ‘int*’ to non-scalar type ‘boost::shared_ptr<int>’ requested
3 Réponses :
Il n'est pas nécessaire d'utiliser ce hack pour obtenir un null (vide) pour attribuer un pointeur à un partagé_ptr code>. Utilisez simplement le constructeur par défaut: partagé_ptr code>, le faire au temps de construction: p> shared_ptr<Investment> pInv = Investment::create();
L'exemple GIVIEN dans la doute, la raison du pointeur NULL dans l'appel du constructeur est l'utilisation d'un Delier personnalisé. Le constructeur du pointeur intelligent n'a pas de version qui ne prend que le Delier personnalisé, d'où la nécessité du "hack".
"STD :: Shared_PTR
Oups, on dirait que c'est un constructeur explicite.
Quoi qu'il en soit, parce que lorsque vous réinitialisez le pointeur, le Deleter personnalisé sera également réinitialisé, non? Ensuite, le null Shared_ptr avec un Delier personnalisé n'a aucun sens dans la programmation réelle, alors étrange d'avoir un tel exemple dans un tel livre
Il convient de noter que partagé_ptr n'a été récemment normalisé que récemment, et qu'il ait peut-être une sémantique différente à un autre point dans le processus de normalisation (bien que je doute, il y a un peu de doute ...)
J'ai supposé que j'avais manqué quelque chose, j'ai refusé de croire que Scott pourrait être confondu! Mais c'est la seule explication que je puisse proposer, +1
Remarque Vous pouvez maintenant plus facilement écrire un null partagé_ptr avec un Deleter personnalisé en utilisant std :: Shared_ptr
Il y a des tonnes de raisons pour lesquelles vous pourriez aimer des objets de manière à être construite par défaut. Tout d'abord, vous souhaitez que le pointeur intelligent soit aussi semblable possible à un pointeur brut, et puisque vous pouvez dire L'une des raisons les plus impérieuses est peut-être que vous pouvez créer des conteneurs avec int * p; (et obtenir un pointeur non défini, non indiqué), vous pouvez aussi Dites partagé_ptr ! ).
partagés_ptr s, et vous pouvez remplir les conteneurs sans affecter des points à jour, puis.
C'est la même raison d'avoir un pointeur brut null - par exemple
dire que vous avez: ceci vous permet de faire:
J'ai essayé de comprendre ici: ideone.com/bujowz . Je ne pouvais pas trouver une explication.
Comme d'autres l'ont souligné, il y a beaucoup de raisons pour avoir besoin d'un NULL Shared_Ptr, tout comme vous avez des pointeurs brus nuls. Mais le vrai mystère est pourquoi Scott a senti le besoin de celui-ci d'avoir un Delier personnalisé.