std::ext STL (was: Re: design doc on alternative pointer support)

[Phil Bouchard]

"Bob Walters" <bob.s.walters@gmail.com> wrote in message 
news:7F3E7EEC-7BD3-4860-87E9-1F1A9F7CE355@gmail.com...
>
> "Phil Bouchard" <philippe@fornux.com> wrote in message
> news:g81m4a$ddc$1@ger.gmane.org...
>
> > Ok it turns out if we delete the node pointed to by the "prev"
> pointer and
> > iterating forward with "next" then everything will be perfect...
>
> OK, so a routine like clear() should be implemented like an iterative 
> erase() with the 'unnecessary' overhead of removing all references to  the 
> object being removed, just in case deallocate() does nothing and  relies 
> on smart pointer behavior.

I think the standards on allocators will have to accomodate smart pointer 
support the following way.  The succeeding functions will have to have 
pointers passed as non-const references to either allow the pointer itself 
to be change or simply the object pointed to in case raw pointers are used:

void deallocate(pointer & p, size_type)
{
}

void destroy(pointer & p)
{
    p = 0;
}


> I also reached the conclusion that iterators *should* reflect the  pointer 
> typedef from the allocator since the allocator is provided as  a policy to 
> the container, and the container in turn yields the  iterator types. 
> (Call it a transitive effect.)
>
> One other question remains: I noticed that your pointer lacked the  means 
> for implicit conversion to a real pointer, and that you used the 
> convention of "&*" throughout the list<> code.  This reminded me of 
> boost.interprocess, and the offset_ptr.  Is there a reason for not 
> supporting implicit conversion?  I did notice it was a pain to work  out 
> the ambiguities which arose when designing the pointer class, but  I think 
> I've reached a point where most 'normal' pointer coding styles  work fine 
> for the _Pointer_adapter<> template, and I'm trying to  determine if there 
> are any other considerations that I have not  thought of.

Implicit conversions are too dangerous and breaks the ownership the smart 
pointer is supposed to have on the object pointed to.  They aren't also 
supported by tr1::shared_ptr.


I'll reply again later today,
-Phil