Educating FORTRAN programmers to use C

[frank glandorf]

Has anyone had any interesting experiences educating FORTRAN
programmers to use C? I recently had a chance to observe a system
which was built by persons who had taught themselves C and whose
previous programming experience was in FORTRAN only. An unusual
aspect of the system was caused by a coding requirement that the
-> operator was permitted to be used in one subsystem only. One
result was that one subsystem was rather large and monolithic.
Another result was the extensive use of macros to disguise the
use of the -> operator. For example, I would write the following
code fragment to walk a linked list (note that all the typedefs
and defines are in include files):

   typedef struct list {
      struct list *next_node;
      int data;
      } List;
   
   List *search(List *first_node, int data) {
      List *p;
      
      for (p = first_node; p != NULL && p->data != data; p = p->next_node)
         ;
      return p;
      }

This system would have a coding style like:

   #define NEXT_NODE(first, ptr) ((ptr) == NULL ? \
      (first) : (ptr)->next_node)
   #define DATA_NODE(ptr) (ptr)->data

   List *search(List *first_node, int data) {
      List *p;
   
      p = NULL;
      while (NEXT_NODE(first_node, p)) {
         if (DATA_NODE(p) == data) break;
         }
      return p;
      }

I am told the reason for this style is to ensure 'correct' access
to structure members. There are a number of modules which are
exempt from the -> rule. I think their existence should have told
the designers that there was something wrong with their method.
Another thing that strikes me about the code is its superficial
resemblence to FORTRAN. The structure references have been made
to look like FORTRAN array or function references. The designers
may have felt more comfortable with this style.

Frank Glandorf -- gcglan at sdrc.uu.net  (513) 576-2061
"If the end of the world was annouced tomorrow, I'd move to Cincinnati
since everything happens there twenty years later" -- Samuel L. Clemens