----- Original Message ----- From: "Dirk Gerrits" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> 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 _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
