Re: [boost] Loki SmartPtr study: Policy orthogonality issues

From: Peter Dimov (pdimov_at_[hidden])
Date: 2002-01-11 08:12:21

From: "Anthony Williams" <anthony_w.geo_at_[hidden]>
> From: "Andrei Alexandrescu" <andrewalex_at_[hidden]>
> Sent: Wednesday, January 09, 2002 11:37 PM
> > If you really want that, I think it's better to implement a limited
> > arithmetic than opening the floodgates by allowing conversions. There's
> > smart pointer arithmetic that doesn't make sense, for example
subtraction
> of
> > unsigned integers. I haven't studied the problem too much yet, but I
guess
> > you can implement arithmetic even without allowing automatic conversion.
>
> Indeed you can --- see my GenericPtr code and article from Overload
> (http://cplusplus.anthonyw.cjb.net/articles.html)
>
> This enables pointer arithmetic on a GenericPtr without accidentally
> deallocating the array --- given a GenericPtr<int> "gpi" that points to an
> array, gpi+3 is a new GenericPtr<int> that also points to the array, and
> increments the reference count. Only when both pointers die is the array
> freed.

I find the idea of enabling pointer arithmetic for shared_array somewhat
questionable, but...

shared_array in

http://groups.yahoo.com/group/boost/files/smart_ptr_3.zip

can be trivially extended to support it by adding

shared_array & operator+= (std::ptrdiff_t i)
{
    px += i;
    return *this;
}

Of course the BOOST_ASSERT(i >= 0); in operator[] will need to be removed.

--
Peter Dimov
Multi Media Ltd.