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

From: Andrei Alexandrescu (andrewalex_at_[hidden])
Date: 2002-01-09 18:37:22

> My point was that you have to think a little bit more about both current
and
> potential users of the library before making any interface design
decisions,
> especially the ones that are mostly based on your personal judgment (if
not
> to say arbitrary). Every such little decision, like dropping a
subscripting
> support, often means a lot of (meaningless) work for poor programmers that
> had been unfortunate enough to become dependant on your library. And they
> have families, you know.

I don't think the effect is that disastruous, and the idea of not fully
support arrays did have a justification behind it, so I guess arbitrary is
undeserved. But I won't go on on wrestling about that.

> > Same argument can apply to adding offsets to smart pointers
> > to arrays. A smart pointer to array should support a subset of
> > pointer arithmetic (adding offsets to the array) just as well as
> > indexing. Why don't boost::scoped_array and boost::shared
> > array support adding offsets?
>
> 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.

> Still, even here the boost
> library allows users to decide for themselves.

Good ad punchline :o). Macros should be a solution of last resort to use
only when other solutions don't work. In this case, policies allow a better
solution.

Andrei

---------------------------------
Check out THE C++ Seminar:  3 Days with 5 Experts
http://www.gotw.ca/cpp_seminar/