> I make heavy use of data structures like
>
> TYPE Foo
> SEQUENCE
> REAL(dp), ALLOCATABLE :: x
> INTEGER(int) :: i
> LOGICAL(lgc) :: initialised = FALSE
> INTEGER(1) :: shim(3)
> END TYPE Foo

> I make heavy use of data structures like

> TYPE Foo
> SEQUENCE
> REAL(dp), ALLOCATABLE :: x
> INTEGER(int) :: i
> LOGICAL(lgc) :: initialised = FALSE
> INTEGER(1) :: shim(3)
> END TYPE Foo

> which works fine for current compilers supporting the TR 15-something
> extension.

> which works just fine within Fortran.

> The tricky bit is to include the Fortran code into a library that is
> called by a C (or similar) MAIN, and do this in an as compiler- and
> platform-independent way as possible (I've been mostly using gcc, but
> also Intel, Sun and VS8 compilers)

> dennis.was...@googlemail.com wrote:
>
> I would say most portable, as mixed language goes, would
> be to do the initialization in a Fortran subroutine.
> (Which could be called from C.)
>
> -- glen

>>dennis.was...@googlemail.com wrote:

>>I would say most portable, as mixed language goes, would
>>be to do the initialization in a Fortran subroutine.
>>(Which could be called from C.)

> Precisely that is what InitFoo is supposed to do...

> The trouble stems from uninitialised array descriptors and the
> opaqueness of the data structures to C.

> I would recommend replacing the ALLOCATABLE with a value of type C_PTR
> (and put the array bounds also in the structure), then use the C Interop
> features to convert to and from Fortran pointers (C_LOC, C_F_PTR, etc.)
> You can allocate the memory in either Fortran or C, as long as you
> deallocate in the same language where you allocated. Remove SEQUENCE and
> make the type interoperable (add BIND(C)).
>
> Any attempt to deal with array descriptors in a portable fashion is
> doomed to failure.

> Dennis Wassel wrote:
> I wrote:

>>>dennis.was...@googlemail.com wrote:
>>>I would say most portable, as mixed language goes, would
>>>be to do the initialization in a Fortran subroutine.
>>>(Which could be called from C.)

>> Precisely that is what InitFoo is supposed to do...
>> The trouble stems from uninitialised array descriptors and the
>> opaqueness of the data structures to C.

>
> You could write Fortran routines whose only function is
> to initialize the array.  Well, ALLOCATE it which will initialize
> the array.  You could also have Fortran routines to read/write
> all the fields of the structure.
>
> That would be usual for object-oriented programming where only
> specific routines are supposed to access data objects, all
> others call those routines as needed.
> ...

>
> I would recommend replacing the ALLOCATABLE with a value of type C_PTR
> (and put the array bounds also in the structure), then use the C Interop
> features to convert to and from Fortran pointers (C_LOC, C_F_PTR, etc.)
> You can allocate the memory in either Fortran or C, as long as you
> deallocate in the same language where you allocated. Remove SEQUENCE and
> make the type interoperable (add BIND(C)).
>
> Any attempt to deal with array descriptors in a portable fashion is
> doomed to failure.
>

> I *think* I understand that suggestion: Using BIND(C), I can replicate
> my types in C and access them in a direct way, which is way cool! Will
> omitting SEQUENCE not mess up the order or allow the compiler to
> include padding bytes - or will BIND(C) guarantee that, even if the
> compiler includes padding, it will do so in exactly the same way as
> the corresponding C code would?

> Dennis Wassel googlemail.com> wrote:

>> I *think* I understand that suggestion: Using BIND(C), I can replicate
>> my types in C and access them in a direct way, which is way cool! Will
>> omitting SEQUENCE not mess up the order or allow the compiler to
>> include padding bytes - or will BIND(C) guarantee that, even if the
>> compiler includes padding, it will do so in exactly the same way as
>> the corresponding C code would?

>
> Yes, that's exactly what it does. I personally think of BIND(C) as a
> special category of sequence, making sure that things like padding are
> done compatibly with C. The standard doesn't express it in those terms,
> but instead ends up saying "sequence or bind(c)" all over the place when
> talking about the properties of sequence types. Since it says almost all
> the same things about both, I'd have thought it cleaner to categorize
> them together. I tried to get J3 to do it that way, but I failed; I am
> convinced that most of my failure was because I didn't manage to express
> my thoughts on it well enough rather than because J3 actually disagreed
> with what I meant. Oh well.
> ...