Re: [boost] [ptr_container] How to shift part of a ptr_vector ?

From: Thorsten Ottosen (thorsten.ottosen_at_[hidden])
Date: 2008-01-02 15:14:07

Phil Endecott skrev:
> Thorsten Ottosen wrote:
>> Phil Endecott skrev:
>>> Herve Bronnimann wrote:
>>>> Phil:  Pardon my ignorance about ptr_vector, but you may be thinking  
>>>> about the wrong STL algorithm: try rotate instead of copy:
>>> Yes, rotate would do something similar to the for loop in my example.
>>>
>>> The point is that ptr_containers can't use mutating std::algorithms; 
>>> instead, they provide their own implementations of some of them as 
>>> members.  rotate isn't one of them, so I need some other way of doing it.
>> You can access mutating iterators over the original containers by 
>> calling .base() no the iterators.
>>
>> They are hen iterators over void*&, so you need to cast or use e.g. 
>> void_ptr_indirect_fun:
>>
>> http://www.boost.org/libs/ptr_container/doc/indirect_fun.html
> 
> Thanks Thorsten.  But I fear that's a worse solution for me, in terms 
> of e.g. readability and lines of code, than simply using a 
> std::container of pointers.  What's ideally needed is for the missing 
> std::algorithms to be added to the ptr_containers, but that could be 
> quite a lot of work. 

I'm definitely not going down that path. The addition of the algorithms 
is partly a sign that the containers are overencapsulated, and partly a 
sign that some algorithms are harder because of the potential presense 
of nulls.
        
> I think that just a swap function would be 
> sufficient for my current needs:
> 
> void ptr_vector::swap(size_type a, size_type b);
> 
> Thinking aloud: this is the first time that I've tried to use 
> Boost.ptr_containers; the last time that I wanted something like this I 
> didn't need the ownership that ptr_containers provides, but only the 
> hidden pointer dereferencing.  I ended up writing something of my own 
> [*].  At the time I wondered if ptr_containers could have been factored 
> into two independent units, i.e. the ownership feature, so that 
> ~container deletes the pointees, and the hidden dereferencing, so that 
> vec[n] is a T& not a T*. 

You can avoid overship with a view_clone_allocator.

http://www.boost.org/libs/ptr_container/doc/reference.html#class-view-clone-allocator

I guess another contender for that could be 
vector<boost::reference_wrapper<T>>, albeit a bit inconvenient without 
operator.() overloading in the language.

> I now wonder whether the layering of the 
> ptr_container over the std::container<pointer> could be explicit, so 
> that the user can get at the underlying container-of-pointers when they 
> want to.  E.g.:
> 
> std::vector<LargeThing*> vec_ptrs;
> ptr_vector_adaptor<LargeThing> vec_largethings(vec_ptrs);  // ctor 
> takes a reference
> // I can now use vec_largethings for read access; if I want to 
> manipulate the
> // underlying pointers I can use vec_ptrs directly.
> 

1.35 introduces a .base() member function in pointer containers s.t. you 
can access the underlying container directly.

I expect to move away from the void* based implementation to allow 
better integration with algorithms, as you and others would like.

-Thorsten