Re: [boost] Re: Re: [review] Formal review of the Smart Containerlibrarystarts today]

From: Pavol Droba (droba_at_[hidden])
Date: 2004-10-04 09:39:08

On Mon, Oct 04, 2004 at 03:46:18PM +0200, Thorsten Ottosen wrote:
> "Pavol Droba" <droba_at_[hidden]> wrote in message
> news:20041004100730.GY9207_at_lenin.felcer.sk...
> | On Mon, Oct 04, 2004 at 02:41:07AM +0200, Thorsten Ottosen wrote:
> 
> | > However, it is true that one reason for the containers to not allow 0 is
> to
> | > avoid troubles with 0 indirection on iterators.
> |
> | I think, you are little be contradictive. One place you allow unsave
> manipulation with
> | the internal data one the other place you are cautious about the indirection
> | problems, that can be easily checked.
> 
> easily? The whole interface is indirected. Doing if( is_null(...) ) in front
> of every
> member function call is not going to help anybody.
>

If you put 0 in the container, you are aware of it, because you have put it there.
Therefore you can act accordingly. It is easy to put asserts in the dereferencing
member functions to guarantie to spot errors.

If you don't use 0 pointers, than you don't have to worry, since the semantics
of smart container does not allow to "create" a 0 pointer.
 
> What is most contradictive:
> 
> 1. to prefer safety in general, but to allow unsafe operations through
> ptr_iterator
> 2. to prefer safety of ptr_iterator, but to allow unsafe operations in general
> 

The difference I'm trying to point out, is that using of 0 pointers can be
well specified and checked in the runtime. It is possible to adjust container
invariants to comprehend this. 
Even if I make a mistake, access violation is generated exactly on the place
where error happens. 
I consider this behaviour on the same safeness-level as all STL structures.

On the other hand, ptr_iterator directly exposes the internal structure
of the container. It is similar as if shared_ptr would allow the access to
its private px member. 
I consider this to be quite big design flaw. It goes againt rules of good design.
Also faulty behaviour is harder to spot and debug.

Regards,

Pavol