M
Marc
Hello,
I read a lot of complaints about how the standard iterator_category
mixes access and traversal. Boost implements its own variant of tags.
Helpers like boost::transform_iterator will usually turn any iterator
into a simple input iterator if *iter doesn't return an lvalue. This
makes it mostly useless to me. Actually functions coded specifically
for boost can see it as something more than an input iterator, but not
regular functions asking for forward iterators and such.
In most code I've seen, we ignore the lvalue requirement and lie by
defining iterator_category just from the traversal properties. We
never had a problem with that.
If boost had an optional parameter allowing to lie about the
iterator_category, I'd be fine. Currently, I have my own
reimplementation of transform_iterator.
How do people here handle this? Do you convert all your code to use
boost iterator categories (meaning you don't use any std:: algorithm)?
Or do you simply not use boost and also lie about iterator_category?
I read a lot of complaints about how the standard iterator_category
mixes access and traversal. Boost implements its own variant of tags.
Helpers like boost::transform_iterator will usually turn any iterator
into a simple input iterator if *iter doesn't return an lvalue. This
makes it mostly useless to me. Actually functions coded specifically
for boost can see it as something more than an input iterator, but not
regular functions asking for forward iterators and such.
In most code I've seen, we ignore the lvalue requirement and lie by
defining iterator_category just from the traversal properties. We
never had a problem with that.
If boost had an optional parameter allowing to lie about the
iterator_category, I'd be fine. Currently, I have my own
reimplementation of transform_iterator.
How do people here handle this? Do you convert all your code to use
boost iterator categories (meaning you don't use any std:: algorithm)?
Or do you simply not use boost and also lie about iterator_category?