Re: C to Pascal translation

On 2006-06-29, Hans-Peter Diettrich <DrDiettrich@xxxxxxxxxxxxxx> wrote:
Hi there,

I'm still busy with my C to Pascal converter, and it starts working
quite well. This is not a question about problems, but a question about
solutions ;-)

Assume that you got C code with multiple source and header files, how
would you like to translate that into Delphi units?

I can find no logical pattern in the way I do this usually. This because
the way header sets are orginazed is not uniform.

E.g. in *nix some structs are moved to separate includes (because they are
e.g. in platform dependant dirs) etc.

For mere library imports a single unit can be created, like Windows.pas
contains the sum of all declarations in a bunch of related (#included)
header files. But when the files also contain code, separate *.pas units
should be created from the *.c files.

For the Windows unit we did this, but it caused some trouble with the wince
one.

Unfortunately then a number of shared identifiers remain, e.g. type names,
which cannot be associated with a specific unit. How would you deal with
such definitions? Create a
<project-name>.pas unit, into which go all shared definitions? And what
about the many declarations from the C standard library, should these go
into another libc.pas unit?

IMHO these should not be auto generated anyway, since that renders the whole
translation horribly Linux (and kernel major version) specific. Unit libc
was IMHO a lost oppurtunity with Kylix.

It worked for unit Windows since the base of the win32 API is fairly static,
but libc isn't. One shouldn't want to mix POSIX funcs and structs with
internal kernel structs. Users don't get the difference and inadvertedly
create apps that are horribly Linux and kernel version dependant while they
shouldn't.

Then there are also macro's and hordes of ifdefs, some of which you want to
convert, and sometimes you just want to optimize a certain defines away.

But perhaps you have better ideas, how to create Delphi units from C
files? Any thoughts or suggestions are welcome :-)

Don't go full cycle. Provide a construction kit with a maybe a few default
paths. Each header sets uses its own macro's that should be dealt with
different again.

Customizability and tools to assist that are IMHO the key. Everybody has its
own tastes, goals, and every header set his own organisation, specific
macro's etc.
.