Boost logo

Boost :

Subject: Re: [boost] Interest check: Boost.Debug
From: Zachary Turner (divisortheory_at_[hidden])
Date: 2009-06-06 10:48:40


On Sat, Jun 6, 2009 at 6:53 AM, Stewart, Robert <Robert.Stewart_at_[hidden]>wrote:

> Gennadiy Rozental wrote
> On Saturday, June 06, 2009 3:15 AM
> >
> > I also have following functions in this module:
> >
> > debugger_break - cause program to break execution in debugger
> > at call point
> [snip]
> > break_memory_alloc - cause program to break execution in debugger at
> > specific allocation point
>
> The function name connotes causing the following memory allocation(s) to
> fail, which is useful in its own right for testing error handling.
>
> How is break_memory_alloc() different from debugger_break() in practical
> terms? IOW, if break_memory_alloc() causes a break at the next allocation,
> it doesn't seem any different than preceding the allocation call with
> debugger_break().
>

The user can't control when the next allocation will happen though. He may
be in a multi-threaded environment and the next allocation might happen from
another thread. It might even happen because you corrupt some memory which
accidentally invokes malloc or new via a bogus function pointer which just
happens to point there (unlikely, though). So it definitely provides
functionality to the user not possible without a separate function for it.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk