On Jan 20, 2005, at 7:24 AM, Bertrand Meltz wrote:
> By the way, this equivalence says a lot about how the compiler is
> expected to arrange arays of derived types.
The compiler has to lay out arrays of derived types just the same as
any other arrays. Quite a few things in the standard essentially
require that. Ok, add the usual caveat that the standard doesn't
actually specify implementation at that low a level. But the
requirements are such that it has to look as though things were laid
out as expected, and in practice it would be awfully tricky to make
things look sufficiently like it without actually doing the layout that
way.
In particular, the array has to look like a bunch of elements, each
element looking just like a scalar of the type (and in fact being a
scalar of the type). The compiler can't implement an array of derived
types the same way as a derived type of arrays (or anyway, it has to do
a darn good job of hiding the fact if it does that).
I won't try to cite all the parts of the standard that depend on this,
but there are several.
Now the structure within a scalar object (including an array element)
of derived type - that's a very different matter. The compiler has a
lot of freedom there. Quite plausibly, the compiler might add padding
between elements (or at the end of them all); and it might reorder
them. Note that this is true (though perhaps less likely) even of
sequence types. You have to have a numeric sequence type or a character
sequence type (or a BIND(C) type in f2003) in order for the standard to
pretty much nix such reorganizations.
--
Richard Maine | Good judgment comes from experience;
[log in to unmask] | experience comes from bad judgment.
| -- Mark Twain
|