I agree that the examples you provide appear safe. While proof by analogy is fraud, it appears to be similar in nature to casts in general. One can provide many examples of the safe use of casts, but generally avoidance leads to better code. I am not familiar enough with the use of boost::interval to take a strong stance, espcially since I do not have metrics to back up my statements. I would urge careful analysis incase the interoperability of types introduces new risks. In the case of template functions where you have template<class T> T foo(T x) { return x -= 1; }, I like to use (when I remember!) boost::numeric_cast since T might be smaller than int. That is, template<class T> T foo(T x) { return x -= numeric_cast<T>(1); } I think I'm probably being pedantic but as I recall the size of int is not stated as part of the C++ specification, only in relative terms to other types. Therefore mixing ints with floating-point types is not guaranteed to be lossless, although on most implementations it will be. I am certainly would concede to those developers that have more experience with this library however, especially if they are doing the work! HTH, Neil Groves On Jan 4, 2008 2:01 PM, John Maddock <john@johnmaddock.co.uk> wrote:
Neil Groves wrote:
Are you certain that mixing floating-point types and integral types is desirable?
floating-point types are, of course, approximations unlike integer types. It is dangerous to mix the two, and the approach to do so should not be allowed even by a policy. Mixing floating point types with integer types implicitly is a poor software engineering practice without merit in my humble opinion.
Implicit type conversion has been a frequently regretted design decision in my experience despite the initial syntactic appeal.
What do you consider is wrong with using integer literals to represent constants, where those constants are indeed integers?
Either in code such as:
my_real -= 1;
or in tables of (integer) coefficients to polynomials?
In this case my_real is a template type, so the conversion may or may not loose precision depending upon the type, but the since result is always represented as the floating point type, then there is no more accurate way to represent an integer than as an... integer.
Converting the other way most certainly is wrong, of course.
All IMHO,
Regards, John.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost