Re: [boost] why no strict ownership smart pointer in boost

From: Larry Evans (jcampbell3_at_[hidden])
Date: 2003-07-01 22:45:30

Howard Hinnant wrote:
> On Tuesday, July 1, 2003, at 08:21  PM, Schoenborn, Oliver wrote:
> 
>>> On Tuesday, Jul 1, 2003, at 17:36 America/Denver, Schoenborn, Oliver
>>> wrote:
>>>
>>>>>
>>>>> On Tuesday, Jul 1, 2003, at 14:38 America/Denver, Boost wrote:
>>>>>
>>>>>> Why is there no strict-ownership smart-pointer in boost?
>>>>>> Just curious to know what the reasons are. Thanks,
>>>>>
>>>>>
>>>>> What do want beyond what boost::scoped_ptr and
>>>>> std::auto_ptr provide?
>>>>
>>>>
>>>> Ability to be used in STL containers, and explicit transfer of
>>>> ownership capabilities (e.g. *no* move-on-copy etc).
>>>
>>>
>>> So what would the copy semantics be?
>>
>>
>> No copy allowed, except temporarily when inside the container to  
>> insert or
>> re-order or transfer from one container to another.
>> Oliver
> 
> 
> You may be looking for something that just doesn't exist in the  
> language yet:
> 
> http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/2002/ 
> n1377.htm#move_ptr%20Example
> 
> This is a pointer with move semantics only, no copy semantics.  And it  
> does not move with copy syntax.  Such a pointer is only a  part of the  
> solution.  It also needs containers that know how to deal with a  
> movable but non-copyable object.  And of course language support makes  
> everything click. :-\
> 
> I have experimented (actual working code) with what you're looking for.  
>  But the tools are *experimental* and not ready for prime time public  use.
> 
> NTL ( http://www.ntllib.org/ ) claims to have this today (I think).  I  
> haven't looked at it closely enough to give a good review, but you  
> might give it a go.
> 

There's also:
 
http://pcroot.cern.ch/TaligentDocs/TaligentOnline/DocumentRoot/1.0/Docs/books/FS/FS_59.html

whose TInstanceOf or TOnlyPointerTo may be what your wanting.

Also, polaris ( http://polaris.cs.uiuc.edu ) had what it called Live and
Ref Wrappers corresponding to Strong and Weak pointers; however, there
could only be a single LiveWrapper to a heap allocated object.  When
that went away, the detructor was called; however, the memory was NOT
reclaimed until all the RefWrapper's also went away.  If a RefWrapper
tried to access an object whose LiveWrapper had gone away, a run-time
error was diagnosed.  This was useful for things like program tree's
where there could only be one owner (corresponding to the AST)  but
maybe several references to an owned object (e.g. a goto referencing
another statement).