debug vector move issue

[François Dumont]

On 09/15/2010 10:47 PM, Jonathan Wakely wrote:
>> When compiled with the necessary attached patch on debug vector it works
>> fine. However when you define _GLIBCXX_DEBUG_PEDANTIC the test a.capacity()
>> == r.capacity() fails. This is because when you create a normal vector by
>> moving a debug one internal memory is transferred but the debug vector
>> _M_guaranteed_capacity is not reseted. This result in the test by the moved
>> debug vector instance 'a' announcing a capacity of 1 when in fact it is 0.
>>
>> I see no real good solution to this problem, _M_guarantied_capacity seemed
>> to be impossible to maintain when the debug container is moved. Maybe
>> putting this data in the allocator could help, I need to investigate.
>>
>> Any thoughts ?
>>      
> (I haven't looked in detail or refreshed my memory of how the debug
> vector works, I've only looked at your attachments)
>
> Can't the move constructor and move assignment set
> __x._M_guaranteed_capacity = 0 ?
>    
The problem is just that we can't because we are moving a debug vector 
to a normal vector. It is the normal vector move constructor that is 
called with a rvalue reference to the debug one seen as a normal vector 
because the debug inherits from the normal. How do you want to know in 
the normal move constructor that the source has a _M_guaranteed_capacity 
that needs to be reseted, that is impossible.
> As Paolo said, the test seems invalid to me, it's trying to verify
> something which is not guaranteed (and in general cannot be.)
>    
Well, I agree that the test is a little bit weird even if it is 
surprising that depending on the way you look at a given instance, as a 
debug one or as a normal one, the capacity returns different values. A 
test that will perhaps looks better for you is:

__gnu_debug::vector<int> dv({0, 1, 2, 3, 4});
std::vector<int> v(std::move(dv));
VERIFY(dv.capacity() == 0);

Once moved the debug vector should be empty without any internal buffer 
left, and in fact it is like that, but capacity still announce 5 even if 
as soon as an element will be added a new buffer will be allocated.

Francois
> Apologies if my cursory glance has meant I missed something!
>
> Jonathan
>