|
Boost : |
From: Aleksey Gurtovoy (alexy_at_[hidden])
Date: 2002-01-09 17:21:04
Andrei Alexandrescu wrote:
> > Something that can be a drop-in replacement for char* buf = new
> > char[n], with all the benefits of automated resource management.
> >
> > > and you're better off with simply calling
> > > GetImpl(sp)[index] to index into the array.
> >
> > Huh? So, basically, you are saying that when one replace a pair
> >
> > char* buf = new char[n];
> > ...
> > delete[] buf;
> >
> > with
> > LokiScopedArray<char>::type buf(new char[n]);
> >
> > she should also went through all the lines in between and
> > replace buf[i] to GetImpl(buf)[i], just because you decided that
> > having an array notation is an unnecessary luxury? I would say
> > that such attitude is unlikely to attract too many users for your
> > library.
>
> Thanks for your kind words.
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.
> 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. Still, even here the boost
library allows users to decide for themselves.
Aleksey
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk