Re: [boost] Re: Re: Loki::SmartPtr (boostified) use as shared resource

From: Phil Nash (phil.nash.lists_at_[hidden])
Date: 2002-04-30 18:37:01

> > (a) no operator->() or operator*() (or any other smart_ptr specific
> > functions there may happen to be)
> > (b) an emphasis on open/ close semantics
[..]
> > (c) a discreet name and concept for resource ownership semantics.
> >
> > Admittedly point (c) and, to a certain extent, point (b) could at least
be
> > partly mitigated by the presence of the fabled template typedefs,
although
> I
> > think it would ignore, in the process, the perspective that led to both
> > these points in the first place).
>
> This is really funny. To me, on the contrary, (a) is a moot point, and (b)
> and especially (c) are important.

Well I'm glad there was some entertainment value at least ;-)
Personally I don't consider (a) a moot point (at least not in the sense of
it not being worthy of discussion).

> To clear a possible confusion, if nobody calls operator-> or operator* for
a
> smart_ptr, they won't be generated at all, even though their generation
> would yield a compiler error. So they're just sitting there harmlessly.

I was not confused about that. But I don't see them as being "harmless". I
might stretch to "mostly harmless" :-)
But to me, the fact that they are there - in the explicit interface of the
object you have in your hand - just doesn't ring right. However I am
prepared to accept that that opinion is not shared by the heavyweight
contributors here. I am obviously in a minority here and will bow to the
community view (for now ;->).

> I do agree that, as Sven also noted, smart_ptr makes it possible, but not
> particularly comfortable, to accomodate various types of resources.

Well, at least I got that token agreement :-)
To me it just "smells bad".

> A good approach to a smart resource would be a carefully designed class
> based on policies. Ideally, some policies would agree with smart_ptr's
> policies that represent the same concepts. Internally, that smart resource
> could use smart_ptr as an implementation device. Or is it the other way
> around? :o)

Ok, I'll bite - it's the other way round! Or even, as I suggested
previously, have a top level RaiiHolder which could be broken down into
smart_resource and smart_ptr.
But I'm running out of arguments (I have more if I think hard enough, but I
don't think they say much I haven't already said).
I think it a shame because I think people will probably not use what could
be quite a powerful feature just because it is hidden away...
(btw, I think it's great that your design does cater for use as smart
resources, and this is certainly better than none at all).

Regards,

[)
IhIL..