On Sat, 17 Mar 2007 07:13:35 -0500 Bob Jamison <rwjj@...127...> wrote:
first, sorry for the late reply,
isinf.h, isnan.h and isfinite.h seem to give us more problems when it comes to cross-platform stuff than any other. Should we merge them into a single .h, like inkmath.h ?
Having had those troubles on gcc-3.2/solaris 8 i'd highly appreciate this suggestion.
Also, to keep it organized, maybe we should have a namespace- or class-scoped set of names that we use, rather than use the same names as the lib calls?
From a C++ point of view this surely is the cleaner solution.
OTOH someone might ask whether it was sufficient and harmless enough to just provide - where needed - the missing calls with their (std::) names and not to bother the main inkscape feature developer (who had to use something like Inkscape::Math::isnan() instead of isnan() otherwise) with those issues.
So I'd like to ask which solution should be preferred:
a) no separate namespace, same names
#if SOME_SPECIFIC_PLATFORM_AND_GCC_VERSION #define isnan(x) __isnan(x) #endif
--> usage example:
a=isnan(b);
b) separate namespace, same function names
namespace Inkscape { namespace Math { inline int isnan(double x) #if SOME_SPECIFIC_PLATFORM_AND_GCC_VERSION { return __isnan(x); } #else { return std::isnan(x); } #endif
} }
--> usage examples: a = Inkscape::Math::isnan(b);
or: namespace IM=Inkscape::Math; a = IM::isnan(b);
--> disatvantage:
using Inkscape::Math::isnan
... will not work on platforms which have std::isnan defined.
c) separate namespace, new function names
namespace Inkscape { namespace Math { inline int IsNan(double x) #if SOME_SPECIFIC_PLATFORM_AND_GCC_VERSION { return __isnan(x); } #else { return std::isnan(x); } #endif
} }
--> advantage:
using Inkscape::Math::IsNan ... will work.
Personally, I'd prefer c).
Markus Schwarzenberg