From: Thorsten Ottosen (nesotto_at_[hidden])
Date: 2004-10-03 19:09:46
"Pavol Droba" <droba_at_[hidden]> wrote in message
| On Sun, Sep 26, 2004 at 10:03:17PM +0200, Thorsten Ottosen wrote:
| > 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
| > providing member is a bad idea
| As I suggested, we need to rewrite only few algorithms from the std library
| 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
| 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
why can't you swap element from different containers?
| This would allow to easily (and naturaly) write most of the 'safe'
are you suggesting to rewrite all the mutable standard algorithms?
| > 3. we risk users will just do &*begin(), &*end() to get the pointers
| If somebody would do this, it is more then clear, that there is a great
| for something to get wrong, unlike when you write
| std::remove(vec.ptr_begin(), vec.ptr_end(), ...)
| which seems very reasonable.
not if you know what remove does..
std::remove( vec.begin(). vec.end() )
will either fail at compile time or do it right.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk