Re: [boost] Re: Re: Intrusive smart pointer

From: Phil Nash (phil.nash.lists_at_[hidden])
Date: 2002-04-18 16:32:53

Aha, looks like I've resubscribed to boost at just the right time :-) (I had
to unsubscribe a few months back as I was getting just too swamped by the
weight of messages!)

If we are talking about introducing policy based smart pointers into boost
(whether this is based on Loki::SmartPtr or not), then perhaps now is a good
time to bring up something I suggested nearly a year ago, went off and
played with for a while, then put on the shelf!
At the time Peter Dimov, IIRC, was talking about adding an option to pass a
function pointer/ object to boost::scoped_ptr to allow clean up code to be
run from the destructor. I wondered if this concept should be extended to a
full-blown scoped_resource class (as well as an auto_resource class and,
perhaps even more interestingly, a shared_resource class).

In this family of classes, rather than storing a pointer we store an opaque
"resource handle" (for example, a file handle). We pass a function object/
pointer into the constructor (or perhaps a destruction policy as a template
parameter) to handle tear down of the resource and either allow the handle
to be passed into the constructor, and thereafter assume ownership, or have
a construction function object/ pointer/ policy.

The primary application for such a family (certainly for scoped_resource and
auto_resource, shared_resource offers additional possibilities) would be to
provide a means of creating RAII wrapper facades for handle-based API's "on
the fly". Since suggesting something along these lines last year, I have
personally had to write many such wrapper facades and wishing I'd spent a
little more time working on scoped/auto_resource.
Of course, writing them is less trivial that it sounds at first, as is the
case with the smart pointers, and, IMHO, involves potentially more
complexity than the smart pointers. It is my feeling, however, that a fair
amount of this complexity is complexity that a manually written wrapper
facade should be dealing with, but is often overlooked (one possible
example - and I'll probably shot down with counter-arguments here - is in
exception safety).

While I'm not suggestion that such a concept be parameterised in as a part
of a policy based smart pointer class, I think there is an overlap of
concept here that suggests a possible unity of effort. I want to have
another stab at this, so would welcome any thoughts and observations (and
offers of help!).

Best regards,

[)o
IhIL..

(P.S. I'll try and find the draft code I came up with last year - although
it was just a starting point - and maybe post some of it if there is
interest).

----- Original Message -----
From: "Andrei Alexandrescu" <andrewalex_at_[hidden]>
Newsgroups: gmane.comp.lib.boost.devel
To: <boost_at_[hidden]>
Sent: Thursday, April 18, 2002 8:02 PM
Subject: [boost] Re: Re: Intrusive smart pointer

> "David B. Held" <dheld_at_[hidden]> wrote in message
> news:a9mu42$c51$1_at_main.gmane.org...
> > Of
> > course, if we're going to make a full policy-based smart pointer,
> > why not just look at the strengths of both boost::smart_ptr and
> > Loki::SmartPtr, instead of cobbling it together in tiny pieces?
>
> Would be great. FWIW, (1) customizing Loki::SmartPtr for COM pointers
takes
> 6 lines of code, (2) there are few, if any significant features of boost's
> smart_ptr that is not being supported by Loki::SmartPtr's design, or
hasn't
> even been implemented already.
>
>
> Andrei
>
>
>
>
> _______________________________________________
> Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost
>