John Maddock wrote:
It sounds reasonable in most cases - however there are situations when a genuine NaN might be required - an example might be where you have a table of statistics, and a NaN is used to indicate "no data".
Ahhh - another trap - semantic overloading. This is a design shortcut - ie mistake which eventually leads to other pain. It's the same problem of assigning meaning to NULL values in databases. The proper way to address this is through a variant which captures what the data really is. I realize that every rule/design principle has its exceptions and we can't (and shouldn't) be telling users what to do, but I'm loath to spend huge amounts of time addressing what for me are corner cases which are side effects of more fundamental mistakes. And however I try to address them, I can't really get it right for this very reason. Robert Ramey
John.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost