[boost] Re: Re: proposal: safe arithmetic class

From: Thorsten Ottosen (nesotto_at_[hidden])
Date: 2003-01-16 05:57:38

<Bjorn.Karlsson_at_[hidden]> wrote in message
news:3D8559AE95B4D611B02C0002557C6C8B3C45C1_at_STH-EXCH...
> > From: Thorsten Ottosen [mailto:nesotto_at_[hidden]]
> > > What would the advantage be over using boost::numeric_cast
> > directly, and
> > > thus explicitly?
> >
> > you would't have to worry about if you forgot a numeric_cast
> > somewhere in
> > your code
> > or if you compiled on a platform with different ranges for
> > built-ins which
> > suddenly
> > could make conversion problems appear.
>
> That you don't have to worry is only true to a small extent - you still
need
> to worry, by protecting the code *somwhere* with a try/catch block.

yes, but why should that be close to the point of error? What use is it to
do

try
{
   xxx = numeric_cast<xxx>( yyy );
}
catch( numeric_exception& e )
{
  // what can I possible do here that makes sense?
}

> This is
> also true for numeric_cast, but then it's straightforward to grok the code
> when reading it.

not if the problems emerged after you compiled on a different platform, then
there might not be any
numeric_cast to look for.

>Obviously, the (potential) problems are always there as
> soon as one starts mixing signed/unsigned types, and when assigning to a
> potentially smaller type; they must always be checked regardless.
>
> > that depends on what the "problem" is. I would say that an
> > _undetected_
> > false conversion
> > is the biggest problem.
>
> Agreed!

good.

>
> > >Doing it "manually", and acknowledging the potential problem by
> > > using numeric_cast is (in addition to ensuring correct behavior)
> > > self-documenting, a property that I think is rather important.
> >
> > by using a wrapper, you also acknowledge a potential problem.
>
> Yes, and when writing code like this: safe_numeric<unsigned char> t=u;, a
> reader can understand that - the code has documented itself. But I don't
see
> an advantage over writing unsigned char t=numeric_cast<unsigned char>(u);
in
> fact, the resemblance with a cast operator makes numeric_cast especially
> intuitive.
this example gives no benefit to the new style.

> On the other hand, using typedefs such as "Char", would convey
> nothing to the casual reader.
if you don't like the name, I guess you could choose what you like, e.g.
safe_char or something. My point is that you should use the safe version
anywhere, not just as above.

> > I might also be beneficial when you are chaning a variable
> > from one type to
> > another; the change
> > might cause conversion problems some different place in the
> > code and/or
> > require numeric_cast
> > to be inserted. By using wrappers this would be detected.
>
> True, but the price of this detection is using wrappers everywhere, which
> defeats the purpose, IMO;

 I don't think it would be that terrible to write char_t, int_t in my
programs instead of
char, int. Especially not if it means I get some more guarantees.

> how should a maintainer know which parts of the
> code contains potential conversion issues when *all* of the code is
implying
> that is the case?

It's also a pretty tough job if you have a 100 numeric_cast spread over 20k
lines of code.
If the error can be reproduced, one could set a break in the exceptions
constructor.

If the error cannot be reproduced, I guess we have a problem (And if anybody
knows, then please tell what you do in that case!).

But look at it from the other perspective. If you used the safe versions,
you will be sure to know if something was wrong with the code.
(And if you have try-catch blocks in strategic places in you program, you
would be able to narrow down where the problem is.)
If you don't, you would have an incorrect program.

I can see another potential use for the classes: during test, one could use
the preprocessor to
substitute all built-ins to check for potential conversion problems.

regards

Thorsten