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
> potential users of the library before making any interface design
> especially the ones that are mostly based on your personal judgment (if
> to say arbitrary). Every such little decision, like dropping a
> 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 +
> operations to make the transition from 'char* buf = new char' to,
> say, 'boost::scoped_array<char> buf(new char)' any smoother - you
> 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
> 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
Check out THE C++ Seminar: 3 Days with 5 Experts
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk