Boost logo

Boost :

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



Boost list run by bdawes at, gregod at, cpdaniel at, john at