[MPI3 Fortran] Results of recent J3 Fortran meeting

[Bill Long]

N.M. Maclaren wrote:
> 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.
> 

Not sure where compiler options come in here, but...

>> 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.
> 

As noted earlier, this is currently an academic issue since the only 
interoperable character is char. If, in the future, we support 
interoperability of a different character kind, then we would need to 
add a new type code (CFI_type_whcar, in addition to CFI_type_char). If 
the programmer wanted to do anything interesting with the characters, 
the type value needs to be checked anyway.  From the type code, the user 
could infer the size of an individual character.   So the problem is 
solvable, and straightforwardly so.  I think it is overkill to add a 
separate member to the struct just to hold the character size. The small 
extra code required to extract the len parameter from already available 
information is better than adding cruft that is unnecessary in 99% of 
the cases.  And either option is better than conflating the KIND and RANK.

Cheers,
Bill



> Indeed, I have come close to describing MPI's MPI_CHARACTER support in
> the above!
> 
> 
> Regards,
> Nick Maclaren.
> 
> _______________________________________________
> mpi3-fortran mailing list
> mpi3-fortran at lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran

-- 
Bill Long                                           longb at cray.com
Fortran Technical Support    &                 voice: 651-605-9024
Bioinformatics Software Development            fax:   651-605-9142
Cray Inc./Cray Plaza, Suite 210/380 Jackson St./St. Paul, MN 55101