|
Boost : |
From: Peter Dimov (pdimov_at_[hidden])
Date: 2001-11-13 08:08:53
From: <brianjparker_at_[hidden]>
> However, I'm not sure I see the advantage in the extra functionality
> that is provided over the (standard) assert().
> The extra functionality that can be provided in the error handler
> (e.g. throwing an exception, continuing etc.) can not be relied upon
> as the assertions will be disabled in the release build.
As I said, there are those people that leave assertions on in release
builds, making them throw an exception. For example, 'canonical' DbC throws
on contract violations; I've never quite bought this idea but I see no point
denying its validity.
> In fact,
> allowing user code to be called in an assertion will lead to subtle
> bugs in release builds when such code is disabled.
Why?
> This just leaves the additional functionality as an aid to debugging,
> but that is surely just a quality-of-implementation issue. Under
> Windows,with VC++, the support for assert() is spectacular- in a GUI
> application a dialogue box is provided that (optionally) allows one
> to call up the JIT debugger and jump to the assertion with a full
> stack trace.
And when your application has taken over the screen (DirectDraw) the
spectacular dialog box is invisible, leading to endless frustrations. ;-)
That's why I need (in my code) to 'hijack' assert's - so I can bring the
usual Windows screen back and see the assertion dialog box - and later the
debugger.
-- Peter Dimov Multi Media Ltd.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk