>| >| What don't you understand in the expression "isnan is a private function"? > >What being private has to do with being trapping or not? > Guillaume point is that this isnan(), being an implementation detail, is known to never recieve a sNAN, so it does not has to account for that situation. Just as you won't put bounds check in an internal function accessing an internal array with a fixed known size.
Your point I can't understand though. Are you saying that an isnan() could trigger a sNAN trap even if it doesn't recieve a sNAN? That is, can a reasonable implementation of it be so wrong as to _generate_ a sNAN? Or are you arguing that the interval library should contend for possible sNAN as input? If the former, I'm sure we are all interested in knowing how can that happen. If the later, I agree with Guillaume that this is a design decision that is already made, and I don't see a compelling reason for changing it. Most likely, if the user inputs sNAN to the interval library, a trap will be triggered way before isnan() is called. An interval library _could_ be designed to cope with sNAN, but this is not the case here and I don't see a real benefit for adding such complexity. Fernando Cacciola _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
