Richard Maine wrote:
>> Yes, and neither to C or Fortran does it seem to matter much in the way
>> of transferring data as they both are just continuous storage of
>> character elements anyway.
>
> Well... not strictly necessarily.

Probably strictly right for all mentioned languages, i.e. the "not
necessarily" part. The only thing C and C++ require, is that if you
increment a pointer to a char by 1, it must point to the next character
in the array. Also sizeof(char) is exactly 1. So in an odd machine, then
maybe they contain som internal padding that probably isn't easily
accessible.


> That's basically exactly what the special C interop provision ensures
> - that a string of length N is stored as a sequence of characters in
> the same way as an array of size N. [...] However, it
> is not required for all character kinds. Imagine multi-byte character
> sets with internal codes to switch subsets.

Regarding the multi-byte character stuff, a similar (but not exactly the
same) alternative is using 16-bit entities storing UTF16 (a subset of
UNICODE). C++ got the new type 'wchar_t' to handle such cases. I was
wondering what the equivalent in Fortran would be.

Since Fortran has the (brilliant) feature of actually being able to
specify the 'kind' (or size) along with the type specification in a
declaration, one is tempted to conclude that the solution is very direct
and simple:

character(1)::asciitxt*32 ! for "old-fashioned" extended ASCII
character(2)::utf16txt*32 ! like wchar_t in C++

and the second would hold a string of 32 16-byte elements. However,
according to your previous answer in this thread, it isn't since the
'*32' part would override the '(2)' part.

Another attempt could then be:

character(2),dimension(32)::utf16txt

but then we would be back to the annoyances with the array vs. string
handling that I originally had a problem with.

--
-+-Ben-+-