[MPI3 Fortran] Results of recent J3 Fortran meeting
nmm1 at cam.ac.uk
Thu Oct 21 14:13:27 CDT 2010
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
>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
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
Indeed, I have come close to describing MPI's MPI_CHARACTER support in
More information about the mpiwg-fortran