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

From: Gennadiy Rozental (rogeeff_at_[hidden])
Date: 2002-05-01 02:00:55

"Phil Nash" <phil.nash.lists_at_[hidden]> wrote in message
news:006401c1f0ab$d084ea10$7eb187d9_at_TimeMachine...
[...]
> > 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->.
>
> 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->?

> > 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:
>
> Nice. I think I saw you talk about this elsewhere. And I admit this would
> mitigate the issue somewhat. But doesn't it depend on template typedefs?
And
> it also adds some extra complexity into smart_ptr itself. With template
> typedefs we could solve the ordering problem externally anyway (I
think)...
> or have I misunderstood your example?

a. template typedefs will make it more elegant. For now we could use type
degerators
b. It does not add any complexity into smart_ptr. It just basically 4
typedefs in public part of smart_ptr.
c. You could probably solve this externaly, but it will be much less
elegant. Foe example, you could provide typedef that specialize only
StoragePolicy, but what if you need to specialize CheckingPolicy. What if
you need to specialize both of them? You end up writing typedefs for all
possible combination of policies.
> 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.

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

Regards,

Gennadiy.