On Thu, Feb 23, 2012 at 5:59 AM, Vicente J. Botet Escriba < vicente.botet@wanadoo.fr> wrote:I would expect the result type of dividing unsigned verified_int and signed verified_int to be signed verified_int. Couldn't this help to avoid the overflow on operator/()?
Of course, if the user assigns a signed to an unsigned, overflow must be checked. I would also prefer that there is no implicit conversion from signed to unsigned verified_int. A specific cast could be used for this purpose.
unary minus operator on unsigned verified_int could also result on a signed verified_int.
I agree with you on preventing implicit conversions. As far as the return types of math operations, the resulting type is always that of the LHS. The leftmost type in a sequence of binary math operations is used for the entire computation, as it is processed left to right.
My philosophy on verified_int, is that overflow should be detected, not avoided. If the author needs a larger data type, then this library will catch that overflow, and the data types can be increased to accomodate the necessary ranges. I do mostly embedded development, and many data types are chosen to minimize space. This library was designed to add overflow detection only, and not implicitly convert data types. That way, once overflow was proven to not exist in a code base, the verified_int could be replaced with the underlying types via some typedefs, and the run-time cost is completely eliminated. If verified_int starts doing more than just checking, than changing to the underlying types would change the system's behavior, an undersirable effect. We agree on this point I believe. Thank you, Ben Robinson
Just my 2 cts, Vicente
______________________________**_________________ Unsubscribe & other changes: http://lists.boost.org/** mailman/listinfo.cgi/boost<http://lists.boost.org/mailman/listinfo.cgi/boost>