Re: [boost] Re: Formal review: Optional library

From: Fernando Cacciola (fernando_cacciola_at_[hidden])
Date: 2002-12-09 17:47:05

----- Original Message -----
From: "Dirk Gerrits" <dirk_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Monday, December 09, 2002 6:14 PM
Subject: [boost] Re: Formal review: Optional library

> Fernando Cacciola wrote:
> > I'm actually trying to vouch for my peek/acquire idiom here.
> > Essentially, the name 'peek()' is intended to convey the fact that the
> > pointer
> > points to a managed object and that the ownership is not being
transfered
> > along with the pointer (as oposed to acquire()).
> > If I manage to make the idiom known enough, the user will know that he
> > can't delete the pointer and that the pointer can be used only
> > as long as the 'source' (the optional<> object in this case) remains
alive.
>
> I still don't see the difference between peek/acquire and get/release.
> Care to enlighten me?
>
> Dirk Gerrits
>
Sure.
peek/acquire are not alternative spellings for get/release, but for get
alone.
Let me explain:
Considering a member function that returns a pointer to something that is
inside an object -a typical 'get()'-, it was noticed that most of the times,
it is not clear how the lifetime of the returned object is supposed to be
handled.
This is a problem that most likely must be solved for each particular case;
however, I realized that

(a) in many cases, the object to which a pointer is being returned always
lives inside the source object (the provider of the get()), so that you can
access the object through the returned pointer as long as the source is
still alive.

(b) in other cases, the object is being handed out through the pointer and
there is some sort of ownership transfer or distribution involved. Modern
interfaces return the pointer via a smart pointer; older interfaces, or
interfaces which can't/won't return managed pointers, simply setup a
documentation contract that specifies how the ownership is handed out or
shared.

I preposed to use 'peek' for the former case (a) since the returned pointer
is intended to be used only to 'peek' inside the object contained in the
source, and 'aquire' for the other managed case.

Here is the original thead with the proposal:

http://aspn.activestate.com/ASPN/Mail/Message/1154956

Fernando Cacciola