Re: [Patch] libstdc++/23425

[Howard Hinnant <hhinnant at apple dot com>]

On Nov 4, 2005, at 10:47 AM, Paolo Carlini wrote:

> Howard Hinnant wrote:
>
>
> > And of course this all needs to be done without breaking exception
> > safety.  Do we run (and pass) Abrahams exception safety test?
> > Additionally, if we don't already have it, we could use some
> > exception safety tests that stress the corner cases of adding,
> > deleting, transferring nodes both on empty deques and non-empty   
> > deques.
>
> About this, Benjamin filed libstdc++/21772, dunno whether you like the
> approach or anyway want to help for it...

Thanks for the link!  I wasn't aware of this (so much history to  
catch up on...).  I've barely glanced at it so far.  I'm having  
trouble finding the definition of cond_throw() (can't find  
forced_exception.hpp either).

I read this in the bug report:

> The general technique I'd like to use is outlined by Matt.

but I'm having trouble locating a reference to that technique.

One thing that worries me about a throwing allocator:

To fully test any given container member function, one must induce an  
exception at every possible point one can be thrown, and then catch  
it and inspect the damage.  I would think that testing a container<T,  
throwing_allocator<T>> would only test those exceptions that the  
container's allocator might throw.  Often the most difficult cases to  
get right are the ones where T's copy ctor or assignment throws.   
Unless I'm misunderstanding something, this technique might miss  
those cases ... hmm... unless the T is another container<U,  
throwing_allocator<U>>.  But that seems like overkill.  I would think  
that a simpler T that merely owns a single piece of memory (one  
allocation per copy ctor and assignment) would make for a more  
efficient test.  Perhaps there is envisioned such a T that takes an  
allocator?

In any event, thanks for the pointer and I'd like to follow the effort.

-Howard