Boost logo

Boost :

Subject: Re: [boost] [iterator] UB when implicitly using default constructed counting_iterator<unsigned>
From: Jeff Flinn (Jeffrey.Flinn_at_[hidden])
Date: 2012-12-07 08:45:25

On 11/30/2012 4:14 AM, Peter Sommerlad wrote:
> Hi Jeffrey, hi all,
> std::copy_n(boost::make_filter_iterator(is_prime{},boost::make_counting_iterator(1u)
> // if the following line is omitted we have undefined behavior, because of uninitialized unsigned value
> // ,boost::make_counting_iterator(std::numeric_limits<unsigned>::max()) // must be different from above value
> ),40,std::ostream_iterator<unsigned>{std::cout,", "});

IMHO, the counting_iterator concern is misplaced. The true culprit is
make_filter_iterator's defaulted end iterator argument. Of all the
iterator types in the standard library, only istream[buf]_iterator(as
pointed out by Steven Watanabe) is valid in this context.

My preferences is to leave counting_iterator as is, and remove the
default from make_filter_iterator. Problematic code would be caught at
compile time. Valid uses would require explicit provision of istream end
iterators. But of course it may be that this horse has already left the
barn. In fact the advent of Range adaptors and algorithms has obviated
this problem.


Boost list run by bdawes at, gregod at, cpdaniel at, john at