Textgeom conditionals

[werthm]

Conditionals in geomtext

Description

geomtext already implements an #include directive that allows for nested geometry files. This contribution extends the functionality by means of conditionals, i.e., by implementing preprocessor-like directives #define, #undef, #ifdef, #ifndef, #else, #endif. This allows, e.g., the inclusion of common geometry parts (also in nested files) based on previously defined expressions.

Example:

#ifdef ADD_SHIELDING
#include geo_shielding.dat
#endif

Expressions can also be used in addition to the :P and :PS commands as static text replacements for input parameters:

#define WORLD_MAT G4_AIR
#define WORLD_HL_X 10*m
:VOLU World BOX WORLD_HL_X 10*m 10*m WORLD_MAT

More flexibility was added by the inclusion of the geomtext parameters (:P and :PS directives) in #ifdef and #ifndef. This allows, for example, to set a variable in a nested geometry file if it has not been defined before:

#ifndef $pos_x
:P pos_x 5*cm
#endif

Checks

• The number of arguments of the newly implemented directives is being checked.
• The correct closing of #ifdef and #ifndef by #endif is checked (missing #endif, #endif without #if).

Limitations and design decisions

• Macro expressions in #define are static text replacements acting on the white-space separated input parameters. They cannot contain white-spaces themselves and the expressions are not being evaluated in any way (as possible for example in the C preprocessor).
• Macro expressions are defined within a single instance of G4tgrFileIn (data structure is not a static member). This means macros definitions are bound to the top input files (added by G4tgrFileReader::AddTextFile()) and their include-hierarchy.

Other changes

• two bugs in the original G4tgrFileIn.cc have been fixed (closing of the top input file, removing of the previously closed file from the list of file names)

[arceciemat]

Sorry for the late answer.
I agree that #ifdef directive can be util
But I cannot agree with the introduction of #define for parameters. I do not see any advantage in introducing a second way to do the same (:P is already static if you put it in the upper file in the hierarchy). And more if users have then two ways to use the parametes (with and without a preceding $, depending on the way it is defined.