🚀 go-pugleaf

In article <14205@lambda.UUCP> jlg@lambda.UUCP (Jim Giles) writes:
>
>Yes, C has some advantages over Fortran.  The ones you mentioned:
>
>Dynamic memory
>struct types
>small integers (or even char)
>macros

Let me add *block structure*.

>              .... Macros are better
>provided as a separate preprocessor (which could even be written
>to be independent of the target language).

If fact, I am using m4, which is cryptic but quite powerful (its SysV
version). I'm using m4 also with FORTRAN to alleviate some of its
shortcomings and there is even a tech. report on this issue

	C. R. Jaensch, U. Ruede, K. Schnepper: "Macro Expansion, a Tool
	for the Systematic Development of Scientific Software," 
	Technische Universitaet Muenchen, Nov. 1988.

>In short, it [FORTRAN-90] has everything on your list but macros -
>but they are mostly used in C to make the awful syntax more palatable.

No, I am trying to do some more than cosmetics. I am using constructs
like
	FOR_ALL_NODES_OF(this_mesh, each_node)
		each_node->component= 0;
	END_ALL_NODES

where *this_mesh* identifies the mesh, and *each_node* will be the
*loop index* (a pointer to the nodes). This technique allows me
to write most of my algorithms independent of the actual storage technique.

My program has evolved through several steps. In the
early versions I still used fixed two-dimensional arrays for storing the
nodes, now it is a linked list. In the old version the macro expanded
to a double loop, in the new one it represents a while loop through the
list of pointers. The macros help me to keep the information how to access the
nodes of a mesh in one central place, instead of spreading it throughout
the program. Changes in the storage structure become comparatively simple
to make, tuning becomes easier, etc.

At present I know no language that allows me to do this directly with
reasonable performance and nice syntax.

>> By the way, the authors of NUMERICAL RECIPES claim that aliased
>> arguments are common coding practice in FORTRAN and use them systematically.
>
>Aliasing is perfectly legal in Fortran, so long as none of the aliased
>variables are assigned to.  I don't remember seeing any example in
>NUMERICAL RECIPES that violated this rule.

I don't have a copy available, but they use illegal alliasing in the
ODE-codes.

Ulrich Ruede