[ET Trac] [Einstein Toolkit] #525: Clean up CCTK_GFINDEX definitions
Einstein Toolkit
trac-noreply at einsteintoolkit.org
Fri Aug 19 12:14:58 CDT 2011
#525: Clean up CCTK_GFINDEX definitions
-------------------------+--------------------------------------------------
Reporter: eschnett | Owner:
Type: enhancement | Status: new
Priority: minor | Milestone:
Component: Cactus | Version:
Keywords: |
-------------------------+--------------------------------------------------
The way in which CCTK_GFINDEX is defined is a bit complex, probably
unnecessarily so. The file cctk.h distinguishes between compilers which
support inlining and compilers which don't. This is probably useless these
days since every compiler supports inlining, and if not, we don't really
expect it to be fast.
If the compiler supports inlining, we define static inline functions,
which may or may not check array indices. If the compiler does not support
inlining, and if CCTK_DEBUG is defined, then we use regular functions
defined in DebugDefines.c, otherwise (i.e. without CCTK_DEBUG) we use
macros.
Overall, the indexing functions are defined three times, including once as
macros. I suggest to simplify this, based on the assumption that every
fast compiler supports inlining. I assume so because (a) the ubiquity of
C++, which relies heavily on inlining, and (b) C99 officially introduced
inlining 12 years ago.
The new setup would have "static inline" definitions (without index
checking) in cctk.h, and would have regular functions (with index
checking) in DebugDefines.c, and would choose between these two
implementations via CCTK_DEBUG.
This would eliminate the macros, and would eliminate the case distinction
based on whether the compiler supports inlining.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/525>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
More information about the Trac
mailing list