On 10/26/05, Noah Stein <noah@acm.org> wrote:
Unless I'm mistaken, this is only a theoretically lossless operation. In the real world of precision issues and whatnot, a conversion back and forth might result in a slightly different answer.
Of course, but such is true for any operations you perform on floating point types, not just unit conversions. For instance, if you multiply two float values together, the result does not have perfect precision. a * b / a does not necessarily yield the same value as a, just like meters_a + feet_b - meters_a doesn't necessarily result in the same value as meters_a. These aren't problems with implicit casting of unit types, they are there with just about all floating point operations other than negation, and they exist because floating point types simply can't have infinite precision without taking up an infinitely large amount of memory. Forcing explicit casts on unit types does not solve this since the floating point operations you'd be using which would require casts would have limited precision regardless of whether or not unit conversion takes place. Aside from all of that, keep in mind that implicit conversions occur only where you'd be explicitly casting anyway, so really you're just making the user type more to perform simple operations. If for some reason you want to mark the conversion explictly with a unit cast, there is nothing stopping you, just like you can always explictly cast fundamental types in C++, however I don't see why that should be required. Really, the main place it's important to explicitly cast would be as the last operation of an entire unit expression, since you may want the end result to be in a particular unit type such as for output or to extract that raw value of a given quantity such that it can be used in more low-level operations. Other than situations like that, the choice for explicit casting should be left up to the user. The point of the library is to make working with units easy as well as potentially more optimized, not unecessarily complicated without gain. Especially in cases where the unit types of the operands may or may not be the same depending on template arguments, forcing explicit casts becomes horribly complex for no reason, and even makes the code harder to read and difficult to write correctly not to mention efficiently. Making necessary conversions automatic through non-explicit constructors solves all of those problems. -- -Matt Calabrese