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

From: Phil Nash (phil.nash.lists_at_[hidden])
Date: 2002-04-29 18:35:31

(re: smart_ptr vs separate shared_resource)
> > they are sufficiently different entities to deserve first class
seperation
> > of identity. This I believe, directly impacts the complexity of the
> > interaction between policies (not vastly, but enough).
>
> In my expirience the only difference was *name* of storage_policy types.
> Could you list those differences that you mention?

I had hoped that I could avoid getting into too many specifics at this stage
as I don't have too much time to contribute, and in particular I don't have
time to patch up my own implementation of shared_resource for presentation
here, which would otherwise make the discussion easier (if I presented it as
is the discussion would more likely degenerate into picking holes in my
implementation).
However, although there are more, I would like to bring up one particularly
important point for now:
After construction and destruction (which are discreet policies for
shared_resources as opposed to a standard smart_ptr) the most important
feature of smart_ptr must be the operator-> overload (and maybe a operator*
overload). With a smart *pointer* you generally don't need or want to access
the raw pointer directly, but rather just call methods on it through these
operators.
However, with a smart *resource* unless you are providing a complete wrapper
with forwarding methods you generally need to get hold of the opaque handle
that you can pass to functions that do the work. In some cases (for example,
a mutex lock) you don't even need this. In short, those accessors that are
so critical to smart_ptrs are pretty meaningless to smart_resources.
If nothing else I think this alone marks a clear delimitation between
smart_ptrs and smart_resources.
Add to this the naming issues I mentioned before (maybe not major issues,
but I feel they do add up to a tendancy that I think is telling of the
branching of design goals), along with a number of other minor points that I
could go lengths to bring out, but are probably not worth it if we disagree
on the main points above, I think there is a strong case for a separate
smart_resource implementation.

> > More importantly they are, IMHO, solving similar, yet subtly different
> > semantic issues. I know this is open to interpretation but it does
strike
> > me as a symptom of over design.
>
> Could you list those differences that you mention?

Err... well one is a pointer one is not. How's that for a start :-)
There is a serious point here. Even just calling smart_ptr a smart *pointer*
clouds the fact that you can use it for managing non-pointer resources. You
cannot use a smart *resource* as if it were a pointer (ie, with -> or *),
which is usually a design goal of smart pointers. Maybe I'm showing myself
up to be totally ignorant here, but I can't see how such a fundamental
difference can be unclear!

> Could you specify in details how smart_resource class will be different
from
> smart_ptr?

Obviously I have partly addressed this question above (and also explained
why I cannot, at this time, do this in great detail). The key points, as I
see it, to recap again, are:
(a) no operator->() or operator*() (or any other smart_ptr specific
functions there may happen to be)
(b) an emphasis on open/ close semantics (this was also brought to the fore
by Sven's posting in this thread - thanks Sven for indirectly supporting my
cause :-) ). In the current Loki::SmartPtr implementation the relevance of
this is reflected by the fact that they are pushed down into an Storage
policy (which strikes me as a less appropriate name for smart resources, but
that's another issue) which is located at the end of the list of template
parameters. In a smart_resource this decision would probably be the most
important and be located at the front of the parameter list (or expressed in
some other more direct way).
(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).

IMHO the only way smart_ptr could peacefully coexist would be, in the
presence of template typedefs and a higher level policy-heavy construct,
say, RaiiHolder, broken down into (various) smart_ptr and smart_resource
typedefs.
We don't have template typedefs just yet, and we do need a starting point...

Regards,

[)o
IhIL..