Andre Poenitz <[EMAIL PROTECTED]> writes:
| On Tue, Aug 02, 2005 at 10:19:59PM +0200, Jean-Marc Lasgouttes wrote:
>> >>>>> "John" == John Spray <[EMAIL PROTECTED]> writes:
>>
>> John> Hi, Attached patch hacks around a crash I encountered scrolling
>> John> through the user guide in lyx-gtk. It would be nice to track
>> John> down what was passing font_metrics::width character counts
>> John> longer than the string passed, but one thing at a time :-)
>>
>> What about a BOOST_ASSERT intead?
>
| Btw, I don't really like BOOST_ASSERT (as well as the 'traditional'
| ASSERT) as it does not offer a possibility to specify what should happen
| in the failure case.
Not quite true... it is our lack of exceptions that dumbs down
BOOST_ASSERT.
| Most failure conditions are not critical for the
| appliction, but simply continuing in the ordinary code path might not be
| acceptable either.
>
| So what I'd like to be used is something like
>
| #define LYX_ASSERT(cond, ret) \
| do { \
| if (cond)
| ;
| else {
| ... something equivalent to BOOST_ASSERT without actual bombing
| ... issue some warning, maybe offer the option to abort
| ret;
| }
| } while (0)
>
| which might be used as
>
| void somePainting(int foo)
| {
| LYX_ASSERT(foo > 42, return);
| ... continue under the assumption foo > 42
| }
>
| These asserts should not be left out in an optimized build.
| This is much more robust than crashing unconditionally or
| removing the ASSERT code from released versions.
then the LYX_ASSER is not an assert anymore.
--
Lgb
