From: Gary Powell (Gary.Powell_at_[hidden])
Date: 2001-03-28 11:33:27
> > I understand your current reasoning, but for VTL to work well, I really
> > could use the extended iterator concepts that Jeremy wrote about.
> I understand. Work like Jeremy's extended iterator concepts is really only
> going to be valuable (and proven!) in the context of a library that needs
> it. Therefore, I suggest you pick it up and try to use it for VTL.
What do you think about container trait concepts?
> > Until
> > then, I can test the result type of the function and select the correct
> > Iterator adaptor
> If you can figure that out, maybe you can also figure out how to unify the
> Transform and Projection iterator adaptors so we don't need two separate
Ok, we'll look into this as well.
> > , but its going to bug people that for a transform on a
> > random access container, they can only do forward access.
> Actually, I probably should clarify again: if the underlying iterator
> supports random access, the transform-adapted iterator will support it,
> It just won't be a RandomAccessIterator, because the reference type will
> wrong. Since the reference type is wrong, for RandomAccessIterator, the
> iterator_category will be just input_iterator_tag.
Yes, but because VTL creates these iterators with the "correct tag", as in
the one from the iterator that is created, and we use that tag to make the
necessary interface. You lose "rbegin(), rend(), operator(), at(),
back()" with only a input_iterator_tag. It also means that algorithms will
not select the most efficient operations, e.g. advance will call ++iterator
repeatedly instead of iterator += etc.
> > It makes no sense to link these two concepts.
> Yeah, it would've been nice if Stepanov had 20-20 foresight, eh? He did
> remarkably well, all things considered.
True enough, just separating algorithms, containers and iterators,
the concept itself is enough, nevermind the ream of code that we
got along with it.
In some ways it has made my life better that he missed the expression
template connection because it has given me something to work on.
We'll keep you posted on developments.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk