[boost] Re: Re: Re: [review] Formal review of the SmartContainerlibrarystarts today]

From: Thorsten Ottosen (nesotto_at_[hidden])
Date: 2004-10-04 11:01:53

"Pavol Droba" <droba_at_[hidden]> wrote in message
news:20041004143908.GA9207_at_lenin.felcer.sk...
| 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.

you might be able to, but other users can't see from the declaration of
ptr_vector<T> that
there is 0 in there.

| It is easy to put asserts in the dereferencing
| member functions to guarantie to spot errors.

these go away in release mode and won't catch code not found during testing.

it might be an idea to have bool CloneAllocator::allow_null or a designated
NullPolicy?

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

on what platforms; on what compilers? you have undefined bahavior and anything
might happen.
and if your test don't run all code or all path through the code, you might
get this behavior
after you dispatched your application.

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

IMO there is a big difference between allowing *all* interface functions to
lead to undefined behavior
and allowing two functions to be potentially misused.

I simply don't understand what you've got against the null object pattern:

- you avoid undefined behavior
- your code logic is simplified

what's there to loose?

br

Thorsten