I'd preferstd::isnan() because it's faster by another x1.5, but this also comes with a slight risk. What do you think?

Let's review this in the next cycle. I have much more profound problems with this 0.12.15 candidate now.

Also, R hasNA andNaN, the standard only has the latter so I prefer R in general for this.

R'sNA is a specialNaN, always has been, and probably will be forever. But I agree it's safer to useR_cppisnan().

R-exts has this to say aboutstd::isnan():

Functions/macros such as isnan, isinf and isfinite are not required by C++98: where compilers support them they may be only in the std namespace or only in the main namespace. There is no way to make use of these functions which works with all C++ compilers currently in use on R platforms: use R’s versions such as ISNAN and R_FINITE instead.

which is a long-winded way of saying, "if you usestd::isnan(), CRAN may yell at you later when it breaks on Solaris". So if we did switch tostd::isnan() we should guard that usage based on whethergcc /clang is being used as the compiler.

Thanks. I missed the "C++11" requirement forstd::isnan():http://en.cppreference.com/w/c/numeric/math/isnan. Let's stick with the API.