--On Monday, June 7, 2004 3:16 PM -0400 Aleksandar Donev
<[log in to unmask]> wrote:
> Richard Maine wrote:
>> I still mostly regard it as a hack for compatibility purposes.
> I disagree---it is often useful to compile a procedure under the
> guarantee of contiguity...
If that were the primary purpose, then one would have hoped that
the standard might have said something about it. :-(
Note that the standard does *NOT* explicitly guarantee contiguity;
that just happens to be a natural implementation. This is not
exactly a coincidence, since compatibility with f77 code was/is an
important issue.
However, it is perfectly legal for a vendor to implement all dummy arrays
with dope vectors that allow for directly handling noncontiguous actual
arguments without copying. Some trickery would no doubt be required for
some of the ugly cases. And compatibility with C or other compilers
(including f77 ones) would probably not be good. Seems unlikely to be
popular with users, but nothing in the standard prohibits it that I know of.
If we actually want to require a property like contiguity, then I'm a big
fan of making the requirement explicit instead of relying on deductions
that some other property will likely be implemented in a way that meets
the requirement. (Did I mention, by the way, that I'm in favor of adopting
such an attribute for f2003+? My currently preference for the spelling is
SEQUENCE. :-))
Of course, we need to understand likely implementations in order to
evaluate performance implications. And we also need to work with the
tools available to us. Since we have no attribute that explicitly
requires contiguity, we have to make do with something else for cases where
contiguity might be important to us. But I still think it important that
we not fall into the trap of thinking that current typical implementation
strategies are actually requirements of the standard.
--
Richard Maine | Good judgment comes from experience;
[log in to unmask] | experience comes from bad judgment.
| -- Mark Twain
