[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