"Pavol Droba" <droba@topmail.sk> wrote in message news:20041003215617.GA6378@lenin.felcer.sk... | 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 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. why can't you swap element from different containers? | This would allow to easily (and naturaly) write most of the 'safe' algorithms. are you suggesting to rewrite all the mutable standard 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. not if you know what remove does.. std::remove( vec.begin(). vec.end() ) will either fail at compile time or do it right. br Thorsten