I have a C routine that I don't have a choice but to use. It's part
of an input/output package called "HDFEOS", an extension of HDF for
use on the NASA EOS project.
The routine takes several unremarkable arguments, and one BUFFER
argument. The specification of the buffer argument is "void* buffer"
and the usage indicates it can be used with any data type.
I have objects of varying type and rank that I'd like to process with
this routine.
I've already noticed that if I use different types in different calls
within the same program unit, some compilers notice the inconsistent
interface. So I've packaged the calls into several modules, one for
each of my types, and put wrappers around the calls, with varying
ranks, to give them explicit interface.
If I give the intermediate BUFFER argument assumed shape, I get an
informative message from one of my compilers that it's unrolling some
loops. If I give the BUFFER argument assumed size, I don't get such
messages.
It seems to me that this is a better situation, since the data that are
ultimately used may allow the compiler to determine that a non-contiguous
array is impossible, so it won't generate a copy (or the possibility of
a copy, preceeded by a run-time check for contiguity).
Rank 1 is not a problem.
My idea in the case of, say rank 3, is to declare BUFFER(1,1,*).
Now suppose my data are declared D(10,20,30), and I put D as the
actual argument (not a section of D). Is this likely to cause a
problem? Will compilers care that the extents of the first two
dimensions are inconsistent? Is there a chance to get a nasty
surprise? My first instinct is that it will work, but in these
gray areas I'm never sure exactly what the implementations do.
I understand that if I put D(1:10:2,3:7,10:30:5) then it will be
copied to be contiguous.
Best regards,
Van Snyder
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|