Boost logo

Boost :

From: Fernando Cacciola (fcacciola_at_[hidden])
Date: 2001-10-26 17:35:39

----- Original Message -----
From: Darin Adler <darin_at_[hidden]>
To: Boost <boost_at_[hidden]>
Sent: Friday, October 26, 2001 7:13 PM
Subject: Re: [boost] casts, exceptions, and asserts

> on 10/26/01 3:00 PM, Fernando Cacciola at fcacciola_at_[hidden] wrote:
> > In other words; I think that the correct distinction is not between
> > and exceptions, but between asserts and error detection.
> > The later uses the exception mechanism explicitely.
> > The former is implementation specific. It can be implemented in terms of
> > thrownn exception invisible to the user. (I'll explain below why this is
> > good idea)
> I agree -- that's precisely what I was trying to say in my original
> When you say "asserts" here, that's my "function type B"; your "error
> detection" is my "function type A". I don't think "asserts" is a good name
> for something that could be an assert or an exception or nothing at all.
> So I think that you and I, at least, see eye to eye on this.
> I think you and I can both agree that Boost should continue to use
> exceptions for "type B" purposes. But we also both would like a
> system for "type A" checks rather than using <cassert> directly,
> to <cassert>. Code in Boost that currently uses <cassert> directly should
> changed to use a new configurable system; perhaps we can call it
> Boost.Assert. I believe this has been discussed a bit in the past.
Totally agreed.
I would also like to see some level of 'error detection' formal system.
Throwing an exception is right, but there can be additional tools for
debugging purposes.

> > Regarding numeric_cast_traits<>, I agree that we need the 'assert in
> > mode' only versions.
> I'm glad you agree.
> > Anyway, notice that the optimized code that I presented
> > actually bypasses the range checking when it determines at compile time
> > it isn't necessary, for instance, when converting from 'float' to
> I did notice that you optimized away the range checking. And this is
> but beside the point. A check that never fires and the lack of a check
> the same behavior.

Should we sketch a "defect management configurable framework"? What about
the debugging tools submitted by Brian Parker a few days ago? Can that be
made to fit here?

P.S: We also agree that assert is probably a bad name because it carries a
fixed semantic, which might or might not match with the semantic of the
system we are discussing here; though I can't think of a good name right

Fernando Cacciola
Sierra s.r.l.

Boost list run by bdawes at, gregod at, cpdaniel at, john at