[MPI3 Fortran] Results of recent J3 Fortran meeting

[N.M. Maclaren]

On Oct 21 2010, Bill Long wrote:
>
>> On Oct 21 2010, Bill Long wrote:
>>> I've lost track of the choice numbers, but if there is no need for 
>>> characters other that C's char, then the simplest solution (for both 
>>> the user and the TR) is to treat character arrays passed by descriptor 
>>> like any other arrays passed by descriptor. The type would be char, and 
>>> the dimension information (dim[] member) corresponds to the Fortran 
>>> dimensions. The elem_len field contains the array element length. 
>>> Because sizeof(char) is 1, the character length parameter is equal to 
>>> the elem_len value, so the character len value is directly available.
>> 
>> It is also the least future-resistant, which is matter of considerable
>> concern.
>
>Not really. The size of the array element in a character array will 
>always have a known relationship to the number of characters in the 
>variable.

But not necessarily one known to the C - that's a fairly common option
in Fortran compilers, and one common requirement is to have a single
(C-based) library for a range of Fortran compiler options.

> For ASCII characters, the relationship is trivial (equal), 
>but it we later wanted to add support for 32-bit characters, the factor 
>of 4  is well known.  ...

That's only one possibility.  Now consider this one.

I write some C code to handle characters, without actually doing
anything very much with them except passing them around.  However, I do
need to know how big a single character is, because some interfaces
have specifications that ask for each of the characters from a 'string'
in order and/or I occasionally have to translate to and from the code I
use in my C.  My code will work irrespective of the size of characters,
provided only that I know what it is.  That approach conflates a
CHARACTER(LEN=4) of 1-byte characters with a CHARACTER(LEN=1) of 4-byte
ones.

Indeed, I have come close to describing MPI's MPI_CHARACTER support in
the above!


Regards,
Nick Maclaren.