ahbarnett
commented
2 years ago Discussion point re how to remove polluting non-safe macro names from the user's view:
Prelude: I'm trying to get all the safe FLT and UTILH namings next... (as per Wenda's long professionalization list :) Adding FINUFFT infront of all is an option, if long. This is what other libs (Eigen etc) seem to do, giving FINUFFT_UTIL_H etc.
But before plunging in comes a design query:
Looking at the project (and forgetting its historical devel), why now can't we keep internal stuff like FLT entirely out of finufft.h, since they are not intended to be seen by the user at all? The user will call our lib with single/double types, just like in our examples/* . FLT is useful for internal build of single/double versions, and tests, but that's it. This would require a pure-user-facing finufft.h different from that used to compile the lib (currently finufft.h brings in a bunch of other internals like dataTypes.h etc... which is what is polluting user macro names.) In this case FLT and other macros would not need to be made "name safe" since the user would never see them. Does anyone know if this is ever done?
Macros allow convenient metaprogramming to avoid code repetition in our source. However, they are the problem for the user who also sees the same .h Maybe the solution is templating in C++? (I'm not used to..)
References for self: https://localcoder.org/why-is-it-not-advised-to-define-macros-in-header-files
Useful GCC cmd to show all preproc macros defined by a source file:
gcc -dM -E src/finufft.cpp -Iinclude
There are 2166 such symbols... lots from FFTW_ and lots of __FLT from glibc, libm etc.
Terrifying.
https://github.com/xsdk-project/xsdk-community-policies shows a good list of professional library requirements. We should aim to fit these and join xSDK.