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

From: Phil Nash (phil.nash.lists_at_[hidden])
Date: 2002-05-01 20:18:31

> > I have to disagree here. If you are able to use operator-> then it is
> surely
> > because what you have is a pointer - not a smart resource (* see
> footnote).
> > And that is precisely my point!
>
> And how do you indision to invoke methods of class R without operator->?

Perhaps we have a different view of what a resource in this instance is. My
definition would be of some opaque handle to an object that is protected
behind a flat API (this may not be an exhaustive definition, but I think it
would normally be along those lines). So you don't invoke methods on class R
by definition! There are no methods on class R to invoke. The methods you
call are actually free functions that take the handle as a parameter.
If you were writing a fully fledged wrapper facade for the handle you will
likely write versions of those API functions as forwarding methods. By the
time you have done that you do not need a smart_resource at all because you
already have the facility to express the RAII aspects in the wrapper class.
If what you are putting in the smart_resource has methods callable through
the -> operator then I would argue that what you have is a pointer after all
(or at least something sufficiently pointer-like to fit the smart_ptr
concept - for example another smart_ptr).

> > This doesn't address the issue that smart_ptr is called smart_ptr. Not
> > smart_resource, or anything else that doesn't suggest non-pointer(like)
> > parameters. It just plain smells wrong to call something smart_ptr when
it
> > may not actually have pointer traits at all.
>
> So, let list of differences in smart_ptr and smart_resource interfaces:
> ....
>
> As far as I understand you sugest that smart_resource does not have
> operator-> and operator*. Then I would like to see answer on my first
> question in this post.

Hopefully the above does answer that now.
Another major difference between smart_ptr and smart_resource is that the
"close" policy is more important (probably undefaultable - wheras a
smart_ptr "deleter" would often be left as default). This may raise a policy
ordering concern, although we can probably work around that. You presented a
candidate solution to this that sounds interesting (although I still have
some reservations which are unimportant to this discussion)
And also falling under the category of differences in the "interface" is, as
stated above (and many times before) the *name* of the interface itself.

Regards,

[)o
IhIL..