Louis Lavery writes:

I'm looking for a transforming iterator. I've looked at the boost transform_iterator but it doesn't quite do what I want. Well, in fact it does a little too much, it passes the dereferenced base iterator to the transform function - I would like it to pass the base iterator itself. The reason being is that the transform function is to return an object containing that base iterator (the object acts much along the lines of a boost graph edge/vertex descriptor).

At the moment I've cut and pasted transform_iterator.hpp, renamed it transmute_iterator.hpp and edited it to remove one char (the dereferencing *) just so as I can try things out.

Oh, I am slow! I was going to ask if such an iterator could be added to boost lib but have just realised that it is trivial for a transmute_iterator to model a transform_iterator.

Hmm, so my question now is - is there some reason why the base iterator is dereferenced before being passed to the function? Wouldn't it be better to let the function decide that?

Not if nearly every use of the thing would have to add a dereference operation. That would make many uses terribly inconvenient, and some impossible (i.e. if you only want to build the function object in place using Boost.Bind or the standard binders instead of Boost.Lambda). It seems to me all you really need to do is use transform_iterator over counting_iterator. counting_iterator enumerates the values of your underlying iterator, and transform_iterator operates on those values. Please let me know if you can't get that to work.

BTW, you guys write some really great stuff, it's very much appreciated. And C++ Template Metaprogramming is mind blowing (especially chapters 10++).

Thanks! It's always gratifying to know we've been useful :-) -- Dave Abrahams Boost Consulting www.boost-consulting.com