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

From: Bjorn.Karlsson_at_[hidden]
Date: 2003-01-16 11:14:05

> From: Thorsten Ottosen [mailto:nesotto_at_[hidden]]
> 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?
> }

Depends on the context, but you're right; typically the try/catch isn't
local. It's still a big difference between locating numeric_casts and using
Char (or whatever the name will be), because in the latter case the
information is integrated (and hidden) within the type. 
 
> not if the problems emerged after you compiled on a different 
> platform, then
> there might not be any
> numeric_cast to look for.

Well, when potentially narrowing conversions are taking place, I'd say "use
numeric_cast". It's what it's for. I agree that it's not always feasible to
identify potential problems correctly, especially in complex expressions.
 
> > 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'd be *very* hesitant about replacing all the builtin numeric types for
UDTs.
 
>  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.

Personally, I wouldn't. For simple conversion problems, the compiler can
(and typically will) issue a warning. For complex expressions, I'd be
willing to use a UDT. Using them for all numeric types, no.
 
> 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.

Yes, but there's also maintenance to consider. It seems we have different
views on this: You want to remove the "problem" completely, I want to
explicitly protect the code containing the "problem".
 
> 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.

Yes, but that's an argument that holds for many different types of added
security; personally, when I'm willing to pay for it, I use other languages
than C++. Still, if complex expressions could be protected, I'd be
interested.
 
> 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.

Agreed, and a good point.

Bjorn