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

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-01-09 19:07:55

----- Original Message -----
From: "Andrei Alexandrescu" <andrewalex_at_[hidden]>

> > They do - if BOOST_SMART_PTR_CONVERSION macro is defined. See, the
problem
> > with pointer arithmetic support is that it's not enough to allow 'buf +
> 10'
> > operations to make the transition from 'char* buf = new char[100]' to,
> let's
> > say, 'boost::scoped_array<char> buf(new char[100])' any smoother - you
> also
> > have to allow an implicit conversion from 'boost::scoped_array<char>' to
> > 'char*' (consider, for example, memcpy-ing the buffer), and _that_ is
> > generally considered dangerous - for the reasons we all know. So, unlike
> the
> > subscripting case, we have a tradeoff here.
>
> 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.

I see Aleksey's point but I guess I don't buy it. A smart array pointer with
arithmetic is a smart iterator whose sequence stays alive as long as any
iterators exist. This has exactly the same applicability to legacy code as a
replacement for pointer-to-array-element as does a smart_ptr standing in for
a pointer to a single dynamically allocated element. In other words, if you
don't supply the unsafe implicit conversion, you have exactly the same
problem at the boundary with any legacy code you're not changing: you have
to do something extra to get the raw pointer out of the smart pointer. You
also get the exact same benefits if you /do/ propagate the smart pointer
type into all the legacy code.

This is really interesting because now we've crossed the boundary between
the iterator adaptors library and a smart pointer library. Maybe some kind
of design unification is called for.

-Dave