vector lightweight debug mode

[Jonathan Wakely]

On 17/11/15 20:49 +0100, François Dumont wrote:
>On 16/11/2015 11:29, Jonathan Wakely wrote:
>> Not doing the checks is also an option. That minimizes the cost :-)
>
>This is controlled by a macro, users already have this option.

True, but we're talking about maybe enabling these checks by default
when building linux distributions.

>>
>> For the full debug mode we want to check everything we can, and accept
>> that has a cost.
>>
>> For the lightweight one we need to evaluate the relative benefits. Is
>> it worth adding checks for errors that only happen rarely? Does the
>> benefit outweigh the cost?
>>
>> I'm still not convinced that's the case for the "valid range" checks.
>> I'm willing to be convinced, but am not convinced yet.
>
>Ok so I will remove this check. And what about insert position check ? I
>guess this one too so I will remove it too. Note that will only remain
>checks on the most basic operations that is to say those on which the
>check will have the biggest impact proportionally.

Yes, that's a good point.

But my unproven assumption is that it's more common to use operator[]
incorrectly, rather than pass invalid iterators to range insert, which
is a relatively "advanced" operation.


>I would like we push the simplest version so that people can start
>experimenting.
>
>I would also prefer concentrate on _GLIBCXX_DEBUG mode :-)
>
>>
>>>    It would be great to have it for gcc 6.0. I am working on the same
>>> for other containers.
>>
>> Please don't do the valid range checks for std::deque, the checks are
>> undefined for iterators into different containers and will not give a
>> reliable answer.
>
>But debug mode is full of those checks, no ?

They're supposed to be guarded by checks for _M_can_compare, if they
aren't that's a regression. For debug mode we can tell whether two
iterators are comparable, because they store a pointer back to their
parent container. We can't check that in normal mode.