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

From: Andrei Alexandrescu (andrewalex_at_[hidden])
Date: 2002-04-29 20:47:09

"Phil Nash" <phil.nash.lists_at_[hidden]> wrote in message
news:007601c1efe5$1a8aae50$10b387d9_at_TimeMachine...
> (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).

This is really funny. To me, on the contrary, (a) is a moot point, and (b)
and especially (c) are important.

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 do agree that, as Sven also noted, smart_ptr makes it possible, but not
particularly comfortable, to accomodate various types of resources.

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)

Andrei