exception safety validation

[François Dumont]

On 09/28/2012 10:14 PM, François Dumont wrote:
>> Hi
>>
>>     I enhance scope of the small exception safety test framework used 
>> to validate different levels of exception safety through the 
>> containers operations. I have added calls to C++ methods 
>> emplace/emplace_front/emplace_back/emplace_hint in C++11.
>>
>>     Doing so I start having propagation_consistency test for vector 
>> to fail. I finally realized that the problem was that the 
>> throw_value_limit used for this test had no move semantic. So the 
>> copy constructor and assignment operator was called sometimes 
>> throwing exceptions. In this case the Standard says that there is no 
>> strong exception safety guaranty explaining why the test was failing.
>>
>>     To fix it I have added for the moment move semantic to the 
>> throw_value_base type so that it never throws. I had to remove the 
>> dg-do run { xfail } in the equivalent deque test that was surely 
>> failing for the same reason.
>>
>>     Now I wonder if there is something in the Standard saying that 
>> move construct/assign shall never throw ? At least, on vector 
>> modifiers it is clearly said that if the move constructor throw it 
>> can have undefined behavior. If move construct/assign can throw then 
>> we might consider a way to control wether or not it will throw 
>> depending on the test. When testing vector and deque it shall not 
>> throw, when testing node based container it can throw. What do you 
>> think ?
>>
>>     I also wonder what are all the try { ... } catch (const 
>> __gnu_cxx::forced_error&) { throw; } in safety.h for ? Is it to 
>> influence the exception callstack ?
>>
>>
>> François
>>
>

Any news ?

Here is an updated proposal using default implementations as much as 
possible.

François

-------------- next part --------------
A non-text attachment was scrubbed...
Name: exception_safety.patch
Type: text/x-patch
Size: 14496 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/libstdc++/attachments/20121103/3a8a71ad/attachment.bin>