Re: [boost] Re: Re: [review] Formal review of the Smart Containerlibrarystarts today (long)

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
> news:20040926194147.GX29008_at_lenin.felcer.sk...
> 
> | 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

*vec.ptr_begin()=p;

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

Regards,

Pavol