Re: [boost] [ptr_container] ptr_vector transfer from C array of pointers documentation

Subject: Re: [boost] [ptr_container] ptr_vector transfer from C array of pointers documentation
From: Number Cruncher (number.cruncher_at_[hidden])
Date: 2010-08-02 04:24:09

  On 28/07/10 16:36, Thorsten Ottosen wrote:
>>
>> As far as I can see, this is exactly what ptr_vector::scoped_deleter 
>> is doing: it will delete any of the copied pointers, but it never 
>> actually deletes the "from" pointer; presumably because you don't 
>> know whether operator new[] was used when allocating it.
>
> Actually it does call delete[] in any case as the destructor of 
> scoped_deleter will call the destructor of the stored scoped_array 
> member. scoped_deleter::release() only means that the T* objects are 
> not deleted, but the internal array always is.

Thanks; I missed the scoped_array member storage.
> Well, a vector<T*> cannot guarantee that the internal buffer is 
> allocated with new T[], I would say its almost guaranteed that it is 
> not. IOW, the function is meant for C-arrays allocated with new T[], 
> not vectors. So no, it won't work. replacing true with false makes it 
> work, but ...

Yes; I never wanted the ptr_vector to try and clear up the std::vector's 
internal array or pointers - just the pointees.

>
> You can still get a leak if insertion fails, but how is that any worse 
> than what your current code can do? Otherwise, use scoped_deleter 
> manually as so:
>
>  v2.scoped_deleter sd( v2, v1.size() );
>  std::copy( v1.begin(), v1.end(), sd.begin() );
>  v2.transfer( v2.end(), sd.begin(), v1.size(), false );
>  sd.release();

I can see how that might work...

>
> A question: why don't you just use ptr_vector where it's needed? Is it 
> s legacy issue?
>

It all started when I needed to return a list of (shallow, non-owning) 
observer pointers from a class. Sometimes that class would create and 
own the pointees itself and sometimes it would just be another 
indirection to an external source. I see that I can use 
view_clone_allocator to remove ownership semantics, but I can't return 
"const ptr_vector<T, heap_clone_allocator> &" one moment and const 
ptr_vector<T, view_clone_allocator> &" the next.

I ended up storing a (possibly empty) ptr_vector in the class, and 
returning "const std::vector<T *> &" with shallow pointer copies of the 
ptr_vector contents if owned, and the indirected pointers otherwise. If 
there were no legacy issues at all, I'd probably just return a 
std::vector<shared_ptr>.

Regards,

Simon.