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

From: Gennadiy Rozental (rogeeff_at_[hidden])
Date: 2002-04-29 23:44:21

"Phil Nash" <phil.nash.lists_at_[hidden]> wrote in message
news:007601c1efe5$1a8aae50$10b387d9_at_TimeMachine...

> 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)

For one thing, it could be very usefull operators for smart resource. Let
say you acquire ans store in you storage policy some resource represented by
class R. How would you call method of class R: most probably you will use
operator->. And for second as Andrei Mentioned those functiond that are not
mentions are not instantiated.

> (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).

I was going to answer Swan message but once you talk about it, here my
answer: smart_ptr could use some kind if named template parameter facility
that will make specifying of ANY parameter very easy. It would be even more
easy if we have a templated typedefs, like this:

template<typename StoragePolicy      = some default,
               typename OwnershipPolicy = some default,
               typename ConvertionPolicy = some default,
               typename CheckingPolicy   = some default >
class smart_ptr
{
public:
       template<StoragePolicy1>
       typedef smart_ptr<StoragePolicy1,

OwnershipPolicy,ConvertionPolicy,CheckingPolicy> storage;

       template<OwnershipPolicy1>
       typedef smart_ptr<StoragePolicy,

OwnershipPolicy1,ConvertionPolicy,CheckingPolicy> ownership;

....

};

Now to specify desired storage policy (keeping all other defaults) you would
write:
smart_ptr<>::storage<YouFancyStorage>

> (c) a discreet name and concept for resource ownership semantics.

Well ... names. I think of it following way:

stored_type - stored type
pointer_type - type of the variable that point to stored value. I.e.
operator-> could be used.
reference_type - some kind of synonim for the stored type. Could be the same
or could be different the same way as param type could be different from
value type in call_traits.

> 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...

I still wait for more real-life *examples* that cause you think this way.

>
> Regards,
>
> [)o
> IhIL..
>
>

Regards,
Gennadiy.