Xref: utzoo comp.lang.c:17612 comp.lang.fortran:1928
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!hc!lanl!jlg
From: jlg@lanl.gov (Jim Giles)
Newsgroups: comp.lang.c,comp.lang.fortran
Subject: Re: fortran to C converter
Message-ID: <11926@lanl.gov>
Date: 12 Apr 89 20:21:18 GMT
References: <1992@csd4.milw.wisc.edu>
Organization: Los Alamos National Laboratory
Lines: 31

From article <1992@csd4.milw.wisc.edu>, by zdenko@csd4.milw.wisc.edu (Zdenko Tomasic):
> In article <158@np1.hep.nl> t19@np1.hep.nl (Geert J v Oldenborgh) writes:
>>Just out of curiosity, how are (double) complex variables translated to C?
> 
> Consider C++, since it  can  define them as objects being object-oriented
> language.

The problem with this is that all the primitive operations on 'objects'
in C++ is done with procedure calls.  So the translation of the following
would contain two procedure call overheads:

      COMPLEX A,B,C
      ...
      A=B*C

There would be a procedure call for each of the primitive operations
(multiply and assignment).  This is hardly what I have in mind when I 
use complex variables.

Of course, there's nothing in the C++ definition that _requires_ that
all functions be implemented externally.  The problem is that the 'inlining'
requires the source (or some intermediate form) of the function library
to be present at compile time.  This would mean (for example) that you
couldn't market a package which implements COMPLEX as 'objects' without
distributing the source.  I've not heard that inlining is available on
any C++ presently marketed.

Actually, C++ 'objects' aren't really objects (as in SmallTalk et.al.),
but the mechanism is really a restricted form of dynamic function overloading.
Genuine function overloading is more general, easier to understand, and could
be just as efficient.