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

From: Pavol Droba (droba_at_[hidden])
Date: 2004-10-04 04:45:58

On Mon, Oct 04, 2004 at 02:09:46AM +0200, Thorsten Ottosen wrote:
> "Pavol Droba" <droba_at_[hidden]> wrote in message
> news:20041003215617.GA6378_at_lenin.felcer.sk...
> | On Sun, Sep 26, 2004 at 10:03:17PM +0200, Thorsten Ottosen wrote:

[snip]
 |
> | 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?
> 

I see, it can be other smart container, just I'm not sure if some kind of
transfer mechanism would not have to be incorporated in this case.

> | This would allow to easily (and naturaly) write most of the 'safe'
> | algorithms.
> 
> are you suggesting to rewrite all the mutable standard algorithms?

I'm not sure where are you heading? We are talking about sorts and 
and permutations. There are not so many of them. If they are provided
as member functions, these would be one-line long. So it yeilds
about 20-30 lines of code all together.

Other mutating algorithms are not usable anyway.

swap functionality would enable to write other '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.
> 
> not if you know what remove does..
> 
> std::remove( vec.begin(). vec.end() )
> 
> will either fail at compile time or do it right.
> 

Are you sure about this? The knowledge about remove algorithm is far not enough
to comprehend how it would work in conjuction with ptr_iterator.

Especialy when it would actualy work, but the program will crash at the destruction
of the smart container because of double-deletion.

Regards,

Pavol