Boost logo

Boost :

From: Pavol Droba (droba_at_[hidden])
Date: 2004-10-03 16:56:17

On Sun, Sep 26, 2004 at 10:03:17PM +0200, Thorsten Ottosen wrote:
> "Pavol Droba" <droba_at_[hidden]> wrote in message
> | In other words, only algorithms like sorting and permutations are safe.
> |
> | Thorsten, please correct me if I'm wrong.
> |
> |
> | I find this behaviour quite dangerous and I don't see any great benefits it
> brings.
> It's always about finding the right balance between idiot safe usage and then
> allowing the programmer to get the job done.

Well I find this problem far beyond idiot safe usage. There is no documentation,
nor safe guard, that can shield you from a problem.

> If ptr_iterator is not mutable we get
> 1. view-clone_manager can sort what-ever it views, but not itself.
> 2. we cannot provide all foreseeable algorithms as members which suggest that
> providing member is a bad idea

As I suggested, we need to rewrite only few algorithms from the std library and
provide an inferface, that would enable to write other algorithms in a way,
that is safe.

I was thinking how to make ptr_iterator safe, and I have an idea. Clearly it
is not feasible to make the iterator handle all possible scenarios, since
it would degenerate to shared_ptr.

But it should be feasible to restrict its operations to those, that are safe.

What I'm suggesting, it that an iterator can return a value that is not
assignable, but swappable with the other one in the container.

So it would be forbidden to write


but it would be possible to write

swap( *vec.ptr_begin(), *(++vec.ptr_begin() );

Internal swap() can check in the debug mode, that both operands are from the same
This would allow to easily (and naturaly) write most of the 'safe' algorithms.

> 3. we risk users will just do &*begin(), &*end() to get the pointers anyway

If somebody would do this, it is more then clear, that there is a great potential
for something to get wrong, unlike when you write

std::remove(vec.ptr_begin(), vec.ptr_end(), ...)

which seems very reasonable.



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