Re: translating C to Java language (S.Bharadwaj Yadavalli)
7 Dec 1996 23:07:07 -0500

          From comp.compilers

Related articles
translating C to Java language zahir@senan.Eng.Sun.COM (1996-12-01)
Re: translating C to Java language (1996-12-03)
Re: translating C to Java language (1996-12-07)
Re: translating C to Java language (1996-12-15)
| List of all articles for this month |

From: (S.Bharadwaj Yadavalli)
Newsgroups: comp.compilers
Date: 7 Dec 1996 23:07:07 -0500
Organization: University of Saskatchewan
References: 96-12-022 96-12-036
Keywords: C, Java

Kindly note: I am NOT an OO expert but am posting this more as
an effort to clarify my comprehension of the concepts. I may be
over-simplifying things but only to get to the fundamentals
rather than to trivialize issues involved. wrote in reply to zahir@senan.Eng.Sun.COM's query:

: > Has any one looked at writing a semantic translator from a C language
: > description to a functionally equivalent Java language description?
: > The translation need not be entirely automatic, human interaction in
: > the conversion cycle for corner cases might be okay with a proper
: > environment assist.
: >
: > Has anyone done a similar translator from C to another object
: > oriented language?

: But C is not object oriented. I always see the job of translation
: as maintaining the structure of the original code. So no object
: oriented code in, no object oriented code out.

But what is so *fundamentally* different with object-orientation
in comparison to modular / procedural nature of, say, C? Isn't
OO a restructured packaging of the modular / procedural style?
By this I mean the following:

A typical C program structure is as follows:

          (optional) global variables
          function1((optional) formal parameters to pass info.)
                              (optional) local variables
                              a bunch of calls to user defined or system functions;
          functions with similar structure as above

Of these functions one of them is designated as "main" to indicate the
entry point to the program.

In an object-oriented program, we just collect together the data items
(variables with "enhanced functionality"?) and functions that operate
upon them and call it a class. (An instance of a more "powerful"
structure with enhanced semantics -- gist of what I read
somewhere). The entry point is designated by a "root" (or whatever)
class. This type of restructuring of modularity opens up opportunities
for conveniences like polymorphism, inheritence and so on. But
fundamentally, I still can not see how OO is semantically different
from procedural / moduler style of programming.

: > Pointers to references or to earlier usenet threads on this topic
: > will be appreciated.

: Eight years ago we wrote a C to Pascal Translator. We also have a
: design for C to Ada ( Java
: ought to be relatively easy in some way, but much harder in others.

Given this "repackaging view" OOP seems to be a move towards program
specification at a higher level of abstraction (more closer to human
mind's abstraction than that of the processor), in my view. (Designing
languages closer to human abstraction levels seems to be the goal in
all the programming language design efforts with a few backtrackings
and forward leaps on the way. That is ofcourse besides the point now).
Thus, translation from C (a language closer to the machine than to
human abstraction levels) to an OO language (a language relatively
farther to the machine but also closer to human abstraction levels)
seems to be difficult when compared to a translation the other way
around -- particularly because, it might involve complicated static
analysis to figure out semantically related functions/procedures (or
methods?) and the variables (data items?) being manipulated by
them. Further, sheerly in terms of performance of the resulting
executable, I wonder if it would be helpful at all. If human
comprehension of a program is the goal, such an exercise may be of

Constructive comments are welcome.



Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.