From: David Abrahams (dave_at_[hidden])
Date: 2005-05-24 19:39:52
Aleksey Gurtovoy <agurtovoy_at_[hidden]> 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
b. unclear on what your functions are doing.
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk