Boost logo

Boost :

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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk