From: Darin Adler (darin_at_[hidden])
Date: 2001-10-26 17:13:48
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 asserts
> 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 a
> thrownn exception invisible to the user. (I'll explain below why this is a
> good idea)
I agree -- that's precisely what I was trying to say in my original message.
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 configurable
system for "type A" checks rather than using <cassert> directly, defaulting
to <cassert>. Code in Boost that currently uses <cassert> directly should be
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.
> Regarding numeric_cast_traits<>, I agree that we need the 'assert in debug
> 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 that
> it isn't necessary, for instance, when converting from 'float' to 'double'
I did notice that you optimized away the range checking. And this is great,
but beside the point. A check that never fires and the lack of a check have
the same behavior.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk