> From: Thorsten Ottosen [mailto:[EMAIL PROTECTED]] > 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 _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
