Your code invokes undefined behaviour.
boost::copy() will call code like this in a loop:
*out = *in;
where 'out' is your ostream iterator and 'in' is a
reverse_iterator.
reverse_iterator, itself implemented using iterator_adaptor,
has an operator* that looks something like this:
UnderlyingIterator::reference operator*()
{
return *boost::prior(base());
}
where UnderlyingIterator is B::const_iterator, and thus
UnderlyingIterator::reference is 'int const&'.
(The boost::prior() call is necessary because reverse_iterator
uses iterator_adaptor in such a way that the underlying
iterator is one element ahead of the element the
reverse_iterator points to. This way, the reversed range's
begin() can be the underlying range's end() and vice versa.)
Here's the undefined behaviour: boost::prior() returns an
iterator by value, which is a temporary in the context of
the the reverse_iterator::operator* call. When that iterator
is dereferenced in reverse_iterator::operator*,
B::const_iterator::operator* returns a reference to a field
of this temporary iterator. reverse_iterator::operator* in
turn returns this reference.
Now when program execution gets to calling the
assignment operator in
*out = *in;
the reverse_iterator::operator* has returned, the
temporary B::const_iterator inside it has been destructed,
and the returned reference is now dangling.
ostream_iterator::operator= tries to read from this
dangling reference, and now anything can happen.
Given that you're invoking undefined behaviour, it is
perfectly normal that an unoptimized build works fine
while an optimized build gives incorrect results.
To avoid the undefined behaviour, I would recommend
making B::const_iterator's reference type be 'int const'
(without the reference) - this can be controlled through
the fifth template parameter of iterator_adaptor:
class const_iterator :
public boost::iterator_adaptor
{
...
int const dereference() const {
return 2 * (*base());
}
};
As a general rule, I would avoid writing iterators that
return a reference to something stored locally. If
you're going to be an lvalue iterator (dereference to
a reference), return a reference to something stored
externally, otherwise be an rvalue iterator (dereference
to a value).
Hope that helps.
Regards,
Nate
