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

From: Phil Nash (phil.nash.lists_at_[hidden])
Date: 2002-04-30 19:21:29

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

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 for second as Andrei Mentioned those functiond that are not
> mentions are not instantiated.

My turn to claim that that is a moot point (but it is starting to sound like
we just disagree fundamentally).

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

> > (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 sa
me
> or could be different the same way as param type could be different from
> value type in call_traits.

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.
However, as I said in my reply to Andrei, I am prepared to drop this on the
grounds that I am not getting any buy in (except maybe some token
concensions from Andrei).

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

Well, I thought I had brought out some salient examples in the form of
the -> operator (and maybe operator*), and the name itself - as well as the
policy ordering, as discussed above.
Off the top of my head, how about:

void Print( boost::smart_ptr<MyType> myObject,
                 boost::smart_resource<HANDLE, file_open_policy,
file_close_policy> file )
{
        fprintf( file.get(), "Value in myObject: %s\n",
myObject->value_string().c_str() );
}
void MyFunc( void )
{
    boost::smart_ptr<MyType> myObject( new MyType );

    {
        boost::smart_resource<HANDLE> fileGuard( MutexLock( handle ),
MutexUnlock );
        boost::smart_resource<HANDLE, file_open_policy, file_close_policy>
file( "myfile.dat" );

        Print( myObject, file );
}

I've tried to illustrate two ways that the open/ close policies could be
specified here. (1) statically as template parameters (the file object) and
(2) dynamically as constructor parameters (the fileGuard).
I'm wondering if both should be supported (not so much of a concern for
smart_ptrs).
Please don't get too hung up on the particular examples (mutexes and file
streams - both of which already have RAII wrappers), they were just
convenient. I don't want to give the impression that unleashing
smart_resource would encourage a return writing C like code :-)
What I like about the mutex example is that it is created entirely on the
fly. No class had to be written to provide a RAII wrapper for it, and we
didn't even have to write some custom policy for mutex lock and unlock.
Although these may not be the best examples, don't you think that even these
would be less obviously smart resources if they were all declared as
smart_ptr? Especially the Print function. All you get coming in is a
smart_ptr and a smart_resource. If you just had a smart_ptr called file
coming in wouldn't you wonder if it was a pointer to a file class
(especially if the resource type wasn't as obviously resourcy named as
"HANDLE")?

If you still disagree entirely then we should probably call it a day here
for now. There is no sense in trading opinions back and forth if there is no
movement. I'll just have to swallow it.

Regards,

[)o
IhIL..

(*) While writing that sentence I could not help the image from forming in
my mind of John Cleese telling Michael Palin, in the Monty Python careers
advisor sketch, "I'm afraid what you've got there is an ant-eater, and not a
lion" :-) Apologies to those not from a (Monty) Python background.