forward declarations in function prototypes
H. Murakami
uunet!tansei.cc.u-tokyo.ac.jp!mhiroshi
Wed Jul 8 19:41:44 PDT 1992
Cc: ncegatimbuk.cray.com
Subject: Re: forward declarations in function prototypes
=============================================
Sorry, I just started to join in this ML, so I did not read the previous
discussions. (Can I have back issues of this ML posts?)
So, may be I am asking FAQ or repeating the same discussion made before,
as if the broken record.
I assume hereby, there is a discussion on the C language extension
to promote the immigration from Fortran to C. (Am I right?)
=============================================
NOTE:
SUBROUTINE SUB(A)
DIMENSION A(N)
COMMON /COM1/N
....
is COMPLETELY correct within the ansi fortran 77.
=============================================
As "," is used in C language as the "comma operator" except the
procedural (dummy or actual) parameter lists.
In the standard C,
a[exp1,exp2];
means, exp1 is evaluated and then exp2 is evaluated.
And then, one dim array "a" is indexed by the value of the exp2.
I suppose, what is now proposed in this ML is,
By using the prototype declaration,
if array a is declared in prototype,
as the procedural argument like a[m,n],
then "," loose the meaning of the "comma operator" and then
array a becomes the two dimentional array.
Am I correct?
Then, assume "a" is defined as the two dimensional array int a[n,m],
what is a[1,2,3],
a[(1,2),3] or
a[1,(2,3)] or
none of above ?
=============================================
In fortran,
subroutine sub(n,a)
dimension a(n*n,n)
....
I think n is assumed to be "not to be changed" inside this routine.
However, I cannot find the description of the rule of fortran to forbid this
anywhere (it is possible that it hides from my eye).
1. Does ANSI fortran prohibit to change the value of the varible
used for dummy array declaration inside the routine?
2. If the ANSI standard permits to alter the value, what is the
interpretation of the size of the array.
case 2.1: The size of the array is fixed through in this routine
the size at the routine was entered.
case 2.2: The size of the array changes whenever the value of "n"
changes.
case 2.2: Implement dependent.
What is the situation of the multi-dim array in extended C language to be?
void sub(int n, int a[n,n])
{
i = a[n,n]
n = n + 1;
a[n,n] = i;
}
=============================================
What is the order of evaluation of the multi-dimensional arrays
subscripts to be?
void sub(int n, int a[n,n])
{
int k = 1;
a[k++,k] = -1 ;
}
=============================================
What if the local array of multi-dimensioned of variable size is avairable?
(For the most mathematical engineering program, with this functionality,
most malloc may be removed.)
void sub(int n, int m)
{
auto int a[n,m]; /* will be taken dynamically at run time */
if (a==NULL) {
fprintf(stderr,"failed to allocate.\n");
exit(ALLOC_FAILED);
}
...
}
=============================================
Isn't it good that we have the array of fortran index order
(column major ordering), and also default 1-origin (and possible change
of origins).
to make ease the porting codes of fortran to c.
Otherwise, just re-write of Fortran array to C array by
A(I,J) --> a[i-1,j-1]
will cause severe inefficiency by paging fault.
So, it should be rather like this:
#define A(I,J) a[(j)-1,(i)-1]
May be for this purpose, some keyword like "fortran" would better be introduced.
(Histrically, keyword "fortran" was reserved for some purpose in K&R.)
void sub1(int n, int m, fortran double a[n,m]);
void sub2(int n, int m, fortran double a[0:n,-1:m]);
(The keyword may be anything else.)
In this case also, ":" must not be interpreted other meanings also.
With this, most fortran mathematical or engineering programs are
easy to port.
=============================================
I have felt very unhappy that there is no exponentiation operator in C.
(The fortran's arithmetic expression, does not contain the intrinsics or
external functions, BUT exponentiation by "**")
As, "*" is havily used in "C", possible replacement for "**" would be "^^".
Think,
SUBROUTINE SUB(N,M,A)
INTEGER N, M
DOUBLE PRECISION A(0:2**N-1,M)
How do you declare the equivalent in (extended) C ?
=============================================
In C language, there is no way to tell that a function for example "sin"
is a mathematical sin function or the users defined random function.
So, there is no way to inline "sin" by the compiler. It is only after
the linking, we may know the "sin" is the math-library sin.
(By dinamic link, even linker cannot tell "sin" is resolved. )
So, C is not able to be as efficient as fortran with this "intrinsic function"
overhead.
What if we have two version of "math.h",
one <intrinsic/math.h> has declaration like:
intrinsic double sin(double x);
the other "math.h" is the ordinal one.
The compiler, seeing keyword "intrinsic", will recognize that
"sin" is the function he may treate it as the intrinsic function "sin".
=============================================
The other difficulty of the immigrating code from fortran to C is the
treatment of the equivalent of the fortran's "ENTRY".
Translating fortran routine have entry to the C code is not so easy.
(Histrically, keyword "entry" was reserved for some purpose in K&R.)
=============================================
What is the way to inform to the C-compiler that there is no overlapped
storage among the variables or arrays?
In fortran, argument passing scheme is either
1) passed by address.
2) call by reference, return by value.
And the program must be free from which implimentation is used.
Most system use 2) for the simple varibles, and 1) for the arrays.
However, this is not necessary be true.
Thus we can assume there is no overlap between the region of arguments
in fortran.
May be by adding keyword "fortran" to the argument, we can let the C-compiler
to assume there is no overlap of the array element to the rest of arguments.
However this may also nasty trick similar to that the keyword "static" is
used to tell the compiler not the strage class but the module scoping.....
=============================================
.....
Hiroshi Murakami
mhiroshiatansei.cc.u-tokyo.ac.jp
More information about the Numeric-interest
mailing list