On Sun, Sep 26, 2004 at 10:03:17PM +0200, Thorsten Ottosen wrote:
"Pavol Droba" <droba@topmail.sk> wrote in message news:20040926194147.GX29008@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