Re: [boost] [1.37.0][serialization] Assertion failed at libs/serialization/src/extended_type_info.cpp:92

Subject: Re: [boost] [1.37.0][serialization] Assertion failed at libs/serialization/src/extended_type_info.cpp:92
From: joaquin_at_[hidden]
Date: 2008-10-21 10:59:20

Hartmut Kaiser escribió:
>> Hartmut Kaiser escribió:
>>     
>>>>         assert(start != end);
>>>>
>>>>         // remove entry in map which corresponds to this type
>>>>         do{
>>>>             if(this == *start)
>>>>                 x.erase(start++);
>>>>             else
>>>>                   ++start;
>>>>         }while(start != end);
>>>>
>>>>         
>>> After looking at this code again I have the impression that it is
>>>       
>> broken
>>     
>>> anyways. You can't safely increment an iterator after deleting the
>>>       
>> object it
>>     
>>> points to: erase(start++).
>>>       
>> I think your objection is wrong: erase(start++) is perfectly safe
>> because the incrementing op
>> is executed before erase is invoked.
>>     
>
> Actually, to be concise, you're invoking undefined behavior. The Standard
> doesn't guarantee any execution order of operations in this context. The
> only thing which is guaranteed is, that the operation executed by erase()
> uses the initial value and afterwards start has been incremented (well,
> whatever happens if you increment an iterator after erasing the element it's
> pointing to).
>   

I still disagree; start++ produces a side effect (std 1.9.7, emphasis mine):

  "Accessing an object designated by a volatile lvalue (3.10), 
*modifying an object* [...]
  are all side effects, which are changes in the state of the execution 
environment.[...]
  At certain specified points in the execution sequence called sequence 
points, all side
  effects of previous evaluations shall be complete and no side effects 
of subsequent
  evaluations shall have taken place."

and as such, it must have taken place by the time the function erase is 
invoked (std 1.9.17):

  "When calling a function (whether or not the function is inline), 
there is a sequence point
  after the evaluation of all function arguments (if any) which takes 
place before execution
  of any expressions or statements in the function body .[...]"

Am i missing something?

Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo