Boost logo

Boost :

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

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, gregod at, cpdaniel at, john at