From: Brey, Edward D (EdwardDBrey_at_[hidden])
Date: 2002-01-25 16:16:16
The static argument example is a good one. I now see how you could want to
change the deleter within the lifetime of a shared_ptr type and even an
object. Without use a Loki-style design, the function object would need to
be kept whether this flexibility is used or not, which isn't perfect, but is
I think a nice feature would be to add a second template parameter allowing
the default deleter to be changed on a type basis. This would allow
creation of a type like shared_cfile, while still allowing heterogeneous
deleters when desired.
If I'm not mistaken, the deleter template parameter would exactly parallel
the Compare template parameter in std::set et al.
From: Peter Dimov [mailto:pdimov_at_[hidden]]
Sent: Friday, 25 January 2002 2:22 PM
Subject: Re: [boost] new version of smart pointer class templates
From: "Brey, Edward D" <EdwardDBrey_at_[hidden]>
> I don't think this will work. There is no implicit conversion between 0
> shared_ptr<FILE>, which is a good thing.
Yes, you could (should?) do this
shared_ptr<FILE> my_fopen(const char* name, const char* mode)
if (FILE* p = fopen(name, mode))
return shared_ptr<FILE>(p, fclose);
throw open_error(name, errno);
instead. Of course this is simply an example.
> On a larger question, what is the design rational for not making the
> a template parameter?
Both approaches have their uses. It is generally expected that the Loki
smart pointer, or some other policy-based design, will cover the template
parameterized case, where you encode the deallocation policy into the type
of the pointer.
shared_ptr<> can be used in situations where you don't want to have the
deallocation policy encoded in the type. For example, if you maintain a
library that has
and you want to change the allocator used for object creation (or even make
some objects static) without breaking compatibility.
Info: http://www.boost.org Send unsubscribe requests to:
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk