N3644 Comparing value-initialized iterators

[Jonathan Wakely]

On 22 November 2013 20:43, François Dumont wrote:
> On 11/15/2013 07:26 PM, Jonathan Wakely wrote:
>>
>> http://www.open-std.org/JTC1/sc22/WG21/docs/papers/2013/n3644.pdf
>> makes it OK to compare two value-initialized iterators, and is one of
>> the few C++14 library features not implemented on trunk.
>>
>> I haven't checked, but my assumption is that the only change needed to
>> the library is to allow examples like this in Debug Mode:
>>
>>    std::vector<int>::iterator i{}; // value init
>>    i == i;
>>
>> Currently this fails because the iterator is singular, but we need to
>> allow it, *without* allowing this:
>>
>>    std::vector<int>::iterator i;  // default init
>>    i == i;
>>
>> I'm not sure how to do this. I thought about trying to play games with
>> uninitialized members that would be zero-init'd by value-init and left
>> uninit'd by default-init, but I gave up.
>>
>
>     Why ? It sounds like the right approach to me too.
>
>     However there is a small issue to this approach. Uninitialized memory
> might look like zero-init one so we will surely miss some invalid usages.

That's exactly the problem.

If I want to rely on random chance whether uninitialized memory gives
the right answer or not then I won't use debug mode!  If I turn on
debug mode I want it to tell me when I break the rules, not just have
a non-zero chance of telling me. In some pieces of code the most
recently freed or deallocated piece of memory might contain a bit
pattern that always makes debug mode give a false negative ... that's
worse than useless, because it gives a false sense of security. "I've
run this code through debug mode for hours and it NEVER fails!" ...
but that's because the failure relies on a particular behaviour of
uninitialized memory that might be 99% repeatable.




> But it is better than false positive so we will just have to live with it as
> I don't think we can do otherwise.
>
>     The other reason why it won't work great for the moment is that there
> are some useless initialization. To begin with the _Safe_iterator_base which
> is zero initializing _M_version, _M_prior and _M_next per default. Some
> normal iterators are also doing zero initialization for nothing, at least
> the unordered container iterators are doing so. By removing those default
> zero-init we would enhance our probability of not missing any invalid usage.

Or make it less deterministic.

Debug mode should be deterministic.


>     I will spend some time on it if you don't mind.

I don't mind, but I'm not confident you'll be able to make
uninitialized memory give reliable results.