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: Claas H. Köhler (claas.koehler_at_[hidden])
Date: 2012-12-07 02:57:34

Hi Steven!

On 06/12/12 18:10, Steven Watanabe wrote:
> AMDG
> 
> On 12/06/2012 12:10 AM, "Claas H. Köhler" wrote:
>>
>> Hi John. You are correct. The following code returns false/0 (with gcc-4.7):
>>
>> 	typedef std::array<double, 10>::iterator T;
>> 	T ita1, ita2;
>>
>> 	std::cout << (ita1 == ita2) <<std::endl;
>>
>> However, you can tweak it like this:
>>
>> 	typedef std::array<double, 10>::iterator T;
>> 	T ita1=T(), ita2=T();
>>
>> 	std::cout << (ita1 == ita2) <<std::endl;
>>
>> and it returns true /1. It is mainly the lack of this functionality which is on my wish-list for the
>> counting_iterator.
>>
> 
> This is still undefined behavior.

Maybe I did not express myself clearly enough, so I'll try again to explain my argument:

I agree that the behaviour of the examples is undefined in the sense, that the standard does not
prescribe its outcome, except for T= T() when T is a scalar type/pointer[...]. That's what I tried to
express when I cited the exact same paragraph you cited in response to an earlier message. (it is
nice to know though, that your copy of the standard is apparently identical to mine, regarding this
paragraph :-)). Unfortunately the standard will not offer a general solution in this case, since it
basically tells us to do whatever we want to.

The implementation of the standard library shipped with gcc (that's the only one I worked with so
far), does guarantee, that the output of the examples I posted is the same every time you call it, so
the behaviour is well defined in the sense that the outcome is predictable. Apparently the VC11
implementation behaves differently as Olaf pointed out.

So the actual question is, whether boost should adopt the strategy used in the gcc implementation,
which allows to default construct the counting_iterator such that the output is predictable, (which I
favour) or whether it should not.

There has been only one argument which actually speaks against initialising the counting_iterator,
because it will prevent one from using a simple debugger to identify malformed code. From my point of
view this argument does not hold, since
 - it helps you only in situations, which could mostly be prevented if the iterator was initialised
 - iterator debugging is preferably done using additional functionality built into most
implementations of the standard library, as pointed out by Olaf. So if boost wanted to offer this
kind of debugging capability, it should be implemented in form of a general debug wrapper for iterators.

But this is just my opinion, and if it is not shared by a majority of boost users, it is clearly not
worth to change the implementation.

Regards
Claas