RE: [boost] Re: proposal: safe arithmetic class
> From: David Abrahams [mailto:[EMAIL PROTECTED]] > > The huge advantage appears when you start looking at arithmetic > expressions. The result of > > if (t < u) > { > x = y + z * w; > } > > could be a lot more predictable if we were working with types that > didn't perform implicit lossy conversions. In some cases, sure. But without some exceptionally creative use of expression templates, you'd have a situation where the ordering of variables determine the validity of the expression - and even then, any extra precision that the implementation uses (e.g. for floating point arithmetic) would probably be lost (and if it's not lost, predictability will suffer). Bjorn ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: proposal: safe arithmetic class
[EMAIL PROTECTED] writes: >> From: Thorsten Ottosen [mailto:[EMAIL PROTECTED]] >> > 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. This is > also true for numeric_cast, but then it's straightforward to grok the code > when reading it. 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! > >> >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 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 char>(u); The huge advantage appears when you start looking at arithmetic expressions. The result of if (t < u) { x = y + z * w; } could be a lot more predictable if we were working with types that didn't perform implicit lossy conversions. -- David Abrahams [EMAIL PROTECTED] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: proposal: safe arithmetic class
> From: Thorsten Ottosen [mailto:[EMAIL PROTECTED]] > > 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. This is also true for numeric_cast, but then it's straightforward to grok the code when reading it. 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! > >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 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(u); in fact, the resemblance with a cast operator makes numeric_cast especially intuitive. On the other hand, using typedefs such as "Char", would convey nothing to the casual reader. > 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; 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? Bjorn ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost