On 19/07/10 9:47 PM, Andrei Alexandrescu wrote:
The plan is to use ranges everywhere. Sorry to disappoint. If you can
find solid arguments for introducing iterators, of course it would be
great if you discussed them in this group.
Well, you mentioned a few yourself in your article.
- With ranges, you double the size of "iterators", which increases the
memory usage of something like Boost.MultiIndex.
- It makes certain algorithm interfaces awkward, such as rotate. I know
you proposed to pass in two ranges, but to me that seems like an
desperate attempt to force ranges into an interface that wants
iterators. In the case of rotate, you've now burdened the programmer
with assuring that the ranges are adjacent (which will probably involve
introducing a local variable for maintenance/readability reasons), and
you've also increased the amount of data you need to pass into the
function by 33%, violating the "Don't pay for what you don't use"
philosophy.
- You're returning more data than is often wanted from some functions
(such as the planned find).
- It makes something like STL's std::list::splice *very* awkward. To do
splice in constant time (as you should) the "range" is going to need to
know about the previous element to its front so that it can update the
linked list. What is the planned interface for this?
My biggest objection to this is that it is essentially an awkward
attempt at abstracting iterators. Ranges are brilliant, and maybe you
could even call them a superset of iterators, but just like we have
vectors despite having matrices, and points despite having lines, we
still want iterators even though we have ranges. They are simply
different things.
