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

From: Phil Nash (phil.nash.lists_at_[hidden])
Date: 2002-04-19 03:24:07

[Phil Nash]
> > 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.

[Andrei]
> I guess I start sounding like a broken record here :o).

Oops, sorry, must be my fault - as I say I've only just resubscribed so you
may have covered a lot of this already.
I may try and brave the archives :-o

> Loki::SmartPtr
> was especially designed to accomodate non-pointer resource. That's why
> StoragePolicy defines two types, namely StoredType and PointerType.
> They can be distinct in the case of facades.

Right, it was more the open/ close behaviour I was thinking would be extra
work, but....

> Also, the StoragePolicy can hold additional state (the afferent
> pointer to function).

... ah that bit I had missed. I'll take another look, but I have lent my
copy of your book out to a friend as part of the study group you are
involved in over on accu. Should get it back next week.

At risk of saying too much about something I haven't looked at properly yet
then, I still have a concern that even if the StoragePolicy could be used to
hold open/ close functions, it doesn't seem to me like the best place to put
it, logically. It does sort of make sense for pointers, but for more general
"resources" open and close need not be soley (or even primarily) concerned
with storage. Also, although I can't think of any killer examples off the
top of my head this time round, I think that resource handling would present
additional problems that would need to be solved that do not apply to
pointers.

Ok, ok... I'll take another look at Loki::SmartPtr before I comment further.

Thanks for your comments,

[)o
IhIL..