(j3.2006) Pre-Processed Programs Poorly Designed? (Was: Select Rank)

[Damian Rouson]

> On Feb 18, 2015, at 12:38 PM, Craig Dedo CAPM <craig at ctdedo.com> wrote:
>  
>             I disagree.  There are several situations that require some kind of pre-processing, much as I dislike it.  One of the more important is that the Fortran standard does not require any specific kind of any data type.  This is explicitly left as processor-dependent.  

I also find include files and pre-processing indispensable for another processor-dependent issue: support for the more recent standards.  Based on the compiler being used (a choice that I hardwire into Makefiles or detect automatically in CMake files), my build system copies pre-processor definitions into the source directory.  For example, if I?m using gfortran, then my make or CMake files to do the following:

cp include_path/gfortran_capabilities.txt source_path/compiler_capabilities.txt 
 
Any source files with features that aren?t universally supported has the line

#include compiler_capabilities.txt

where the included file contains lines like

#define COMPILER_LACKS_IMPURE
#define COMPILER_LACKS_DERIVED_TYPE_IO
#define COMPILER_LACKS_COLLECTIVES

The above three are the most common cases of processor-dependence in my current codes.  (I don?t have a reasonable workaround for missing coarray support, which I use in most of my projects.)  The last #define above so important from a performance standpoint that I recommend users write their own collectives matching the proposed Fortran 2015 syntax and then use something like

#ifdef COMPILER_LACKS_COLLECTIVES
use my_collectives_module, only : co_sum
#endif

This minimizes code changes once more compilers provide collective subroutines.  (Currently only gfortran and Cray do.)   Until the compiler landscape is more even in its support for recent standards, I don?t know a good alternative to the above approach other than abandoning the relevant features altogether.

Damian


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.j3-fortran.org/pipermail/j3/attachments/20150218/c2b8e328/attachment-0001.html