|Converting Pascal to C++, C# or VB email@example.com (Steve) (2006-04-03)|
|Re: Converting Pascal to C++, C# or VB firstname.lastname@example.org (Marco van de Voort) (2006-04-08)|
|Re: Converting Pascal to C++, C# or VB email@example.com (2006-04-08)|
|Re: Converting Pascal to C++, C# or VB firstname.lastname@example.org (John O'Harrow) (2006-04-08)|
|Re: Converting Pascal to C++, C# or VB DrDiettrich@compuserve.de (Hans-Peter Diettrich) (2006-04-08)|
|Re: Converting Pascal to C++, C# or VB email@example.com (Eric) (2006-04-08)|
|Re: Converting Pascal to C++, C# or VB firstname.lastname@example.org (George Neuner) (2006-04-08)|
|Re: Converting Pascal to C++, C# or VB email@example.com (Martin Ward) (2006-04-08)|
|Re: Converting Pascal to C++, C# or VB firstname.lastname@example.org (Neelakantan Krishnaswami) (2006-04-08)|
|Re: Converting Pascal to C++, C# or VB email@example.com (firstname.lastname@example.org) (2006-04-08)|
|Re: Converting Pascal to C++, C# or VB email@example.com (Marco van de Voort) (2006-04-09)|
|[7 later articles]|
|From:||Hans-Peter Diettrich <DrDiettrich@compuserve.de>|
|Date:||8 Apr 2006 17:02:57 -0400|
|Posted-Date:||08 Apr 2006 17:02:56 EDT|
> I have some legacy machine control code written in ISO std Pascal that I
> would like to convert to one of the languages supported by our current
> development environment : MS Visual Studio .NET 2003. So that means C++, C
> sharp or VB.
> It's a big chunk of code - about 500k lines in 200 files. I currently have a
> translator that converts it to Delphi. This enables us to run it on a PC,
> but it will not fit easily with our newer code which is in C++ and C#.
Delphi can produce .NET code, so you'll have little problems with the
integration of multiple .NET languages. In former times support for
C++ and Pascal came in separate Borland tools, but now Delphi can
handle both languages in the same project. In so far I'd suggest that
you use Delphi in your migration.
> I plan to extend this translator to generate the new language
> too. The translator creates an AST for all the source, and keeps
> track of publics/externs. Several passes are then made over the AST
> to generate the Delphi units. It's a complicated process, especially
> for the structured constants.
Some time ago I wrote an C to Delphi converter (in Delphi ;-), for
declarations only, and I found no need for multiple passes there. A
Pascal to Delphi converter should be much simpler, though I admit that
I don't know what problems you are facing from your different Pascal
> So the question is which language to use? I know C++ a little, but
> the other two are new to me.
In .NET applications you should use a .NET language. But be warned,
the .NET environment differs significantly from traditional Pascal or
C++ environments (garbage collection...).
> So far the main obstacle I can see with C++ is the nested routines
> of Pascal. I don't know of any way to do this in C++.
GNU C/C++ (gcc) also allows for nested subroutines, but I don't know
about Borland or Microsoft idioms, in detail for .NET.
> Initial investigation suggests that the struct in C# might be a
> suitable alternative. It has to allow access to constants, types and
> variables declared in an outer scope.
Objects (struct) can be a solution, as long as no recursion will
occur. Another solution is packing all shared local variables into
structs, and passing references to the outer struct(s) in additional
parameters to the subroutines.
> We also have a few instances of Pascal procedural parameters. Can
> these be emulated?
Yes, with pointers to procedure types, e.g.
typedef void (*proctype)(<args...>);
(no guarantee for correct syntax, I don't like C, to put it mildly ;-)
> Fortunately no-one ever used conformant arrays. :)
> I welcome comments/advice.
You might be better off with traditional Pascal/C++ instead of .NET,
if that's an acceptable solution. Even if you finally have to use
.NET, the language specific part of your port will be supported very
well by Delphi (together with BCB for older Delphi versions). Once
that solution works, you can migrate all the code to .NET, whereby
you'll have to face only the platform specific problems.
Return to the
Search the comp.compilers archives again.