Re: [boost] [iterator] UB when implicitly using default constructed counting_iterator<unsigned>

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.

Jeff