Aleksey Gurtovoy <agurtovoy@meta-comm.com> writes:
Maybe you could add some commentary?
Sure. Both of the marked lines above invoke undefined behavior on dereference of the corresponding composite transform iterator because its 'operator*' by the iterator is basically equivalent to this:
int const& operator*() const // ^^^^^^^^^^ { // returning a reference to a member of a temporary object // that will be destroyed at the end of the function block scope return make_x( *base() ).get_i(); // #1 // return X( base()->x ).get_i(); // #2 }
Oh. Well, I'm not sure that separating transform_iterator and projection_iterator would help here. AFAICT this issue only really applies when using make_transform_iterator, and only when you're a. assuming a transform_iterator always returns by value and b. unclear on what your functions are doing. OR c. You expect transform_iterator to be a perfect drop-in replacement for the transform_iterator from the earlier Boost library, which I admit is a fair expectation. Maybe we need a make_transform_iterator variant that allows us to force a by-value return or something? -- Dave Abrahams Boost Consulting www.boost-consulting.com