Re: [boost] New Boost.XInt Library, request preliminary review

Subject: Re: [boost] New Boost.XInt Library, request preliminary review
From: DE (satan66613_at_[hidden])
Date: 2010-03-31 13:16:49

on 31.03.2010 at 20:15
 Scott McMurray wrote :
> I have a sketch of a way to offer both here:
> http://lists.boost.org/Archives/boost/2010/03/164346.php

i thought a while and came to a conclusion that
making different flavors of xint as distinct types or different
specializations or even policy based implementation is a good idea
indeed

particularly having xint::raw_integer and xint::integer (exception
blocking and NaN are here) makes sense
these two (possibly) implicitly share the value for run time efficiency
(for fast convertions of one to another)

then if 'op(xint::raw_integer)' wraps 'op(xint::integer)' the former
checks for NaN and throws (otherwise 'op(xint::integer)' throws itself)

if 'op(xint::integer)' wraps 'op(xint::raw_integer)' then the former
catches the possible exception and returns NaN if exceptions are
blocked but this case seems less efficient

actually there are some things to think of

>>Â A "half-signaling" NaN (quietly manufactured but noisy when touched)
>> seems to me a near-useless middle ground.
> This is a good point.  When the option of a policy-based scheme for
> exception control was brought up I just sort of assumed on principle
> that it would somehow be useful.
> Can anyone give an example where a middle ground would be best?

i vote for quiet NaN since operations are throwing already by default
but actually the original design was sane too
for example

  xint::integer i;
  while ((i = foo())==NaN)  //doing some important work
    ask_user_what_to_do();  //failed! worth it to try again?

i think this is conscious
was NaN a signaling one this would not be possible
but if i try accidentally to use a NaN in an operation it throws like
in the following example

  xint::integer i = bar(a);  //fails sometimes because of its nature
  //if (i==NaN) do_something();  //oh! forgot to check if bar()
  i *= 2;                        //succeeded!

here to indicate that 'bar()' may fail not as an exceptional situation
but due to its nature we say that it returns NaN
was NaN a signaling beast 'bar()' would throw anyway -- exception
missuse

-- 
Pavel
P.S.
if you notice a grammar mistake or weird phrasing in my message
please point it out