Prev: Module interface for an external procedure
Next: interactive command editting
From: Richard Maine on 24 Feb 2010 16:11
ksmith <kwmsmith(a)gmail.com> wrote:

> On Feb 24, 12:58 pm, m_b_metcalf <michaelmetc...(a)compuserve.com>
> wrote:
> > On Feb 24, 6:48 pm, ksmith <kwmsm...(a)gmail.com> wrote:
> >
> > Your example is not standard conforming -- it defines two different
> > types (although they are identical in every respect). See also the
> > last paragraph of Section 7.11 of "Fortran 95/2003 Explained". A
> > compiler that 'allows' it is in error.
....
> My usecase is for a program I'm creating that automatically generates
> C wrappers for fortran code, leveraging the ISO C BINDING module & the
> C binding functionality. I'm running into some snags with derived
> types, but the restrictions make sense. I want to be sure that the
> generated code is standard conforming.

Craig (appropriately) mentionmed SEQUENCE. If this is for C-related
wrappers, let me note that a BIND(C) type has the same effect as
SEQUENCE in this regard. In fact, I personally view BIND(C) derived
types as being a special variant of SEQUENCE. They act the same way in
almost every regard, with just the added bits about being compatible
with C. I didn't manage to convince the committee to express it that way
in the standard (I tried), but I still think of it that way.

Do note that because the committee rejected that viewpoint, you can't
declare a BIND(C) type to be SEQUENCE. It acts a lot like SEQUENCE, but
you aren't alowed to declare it that way; you can declare it either
SEQUENCE or BIND(C), but not both.

--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain
First  |  Prev  | 
Pages: 1 2
Prev: Module interface for an external procedure
Next: interactive command editting