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-... 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