Home > Archive > Compilers > April 2006 > Converting Pascal to C++, C# or VB
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Converting Pascal to C++, C# or VB
|
|
|
| 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#. 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.
So the question is which language to use? I know C++ a little, but the other
two are new to me.
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++. 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.
We also have a few instances of Pascal procedural parameters. Can these be
emulated?
Fortunately no-one ever used conformant arrays. :)
I welcome comments/advice.
| |
| Marco van de Voort 2006-04-08, 7:03 pm |
| On 2006-04-03, Steve <steve@rh12.co.uk> wrote:
> two are new to me.
>
> 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++. 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.
> We also have a few instances of Pascal procedural parameters. Can these be
> emulated?
C/C++ have callbacks too, so for the simple case not that much of a problem,
but when nested procs get involved, it might be hard.
Specially since that under ISO nested procedures passed to other functions as procedure
variables have access to their parents context (this is one of the things
the Borland line doesn't support). IOW, such procedures are not pure
function pointers, but functionpointer + a framepointer.
So the first thing would be to check if nested procedures are passed as
prcvar and if they access parent procedures frames (parameters, vars)
| |
| Torben Ęgidius Mogensen 2006-04-08, 7:03 pm |
| "Steve" <steve@rh12.co.uk> writes:
> 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.
There is a freeware Pascal to C translator called p2c (see
http://www.synaptics.com/people/daveg/). This might be a good place
to start.
Torben
| |
| John O'Harrow 2006-04-08, 7:03 pm |
| Converting from Delphi Object Pascal to C# should be much easier than
converting to C++. The Delphi and C# languages are very similar (Anders
Hejlsberg, the lead C# architect at Microsoft was the main developer of
Delphi in its early days).
--
regards,
John
| |
| Hans-Peter Diettrich 2006-04-08, 7:03 pm |
| Steve wrote:
>
> 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
idioms ;-)
> 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.
DoDi
| |
| George Neuner 2006-04-08, 7:03 pm |
| On 3 Apr 2006 01:39:03 -0400, "Steve" <steve@rh12.co.uk> wrote:
>I currently have a translator that converts [ISO std Pascal] to Delphi.
>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.
>
>So the question is which language to use? I know C++ a little, but the other
>two are new to me.
Hopefully someone will have already done such a translator - it is not
something you want to tackle without having a thorough understanding
of both the source and target languages. If you _really_ do want/have
to do this, here are a few things to chew on.
As you have already surmised, you can't directly translate Pascal into
any of those languages. The simplest to work with would be C++ ...
the others have some intrinsic features [such as GC] that can further
complicate a straight forward translation. The difficulty level
depends on how many of Pascal's incompatible features you want to
handle and how closely you wish the generated code to visually match
the original Pascal source.
Nested Routines:
Simulating nested routines is fairly simple - you turn the top level
function or procedure into a C++ "function" object - that is an object
that overloads the call operator "()". You convert the shared local
variables and top level parameters to member variables and any nested
routines into member functions [or recursively, into member function
objects]. See example below.
You can use and pass references(pointers) to function objects to
simulate procedure variables and parameters. C++ allows taking the
address of a function and passing it to another function, but because
all C++ functions are top-level, that won't help with nested scoping
issues so it is best to use function objects and references
throughout.
Arrays:
The type of a Pascal array includes shape information [dimension,
size] as well as element type. Additionally, in Pascal any array may
have a displaced origin, ie. negative indices.
In C++, arrays have a single dimension and indexing is zero based -
period. Code using negative indices must be rewritten to use zero
based indexing.
Additionally, C++ arrays do not retain their shape information as they
are passed around - all that is passed is a pointer to the first
[zeroth] element. If the shape of an array is known at compile time,
a formal array parameter of that shape can be specified in the
function prototype, but otherwise you must somehow pass the shape
information along with the array.
You can create an "array" object which remembers the shape and element
type, allocates/deallocates the element memory, maps negative indices
appropriately and overloads the index operator "[]" to access the
elements. You can choose to create a separate class for each order
[1d,2d,etc.] of array used, or just recursively use a 1d array class
for "array of array" style. The first is more efficient for higher
order arrays, the second slower but more flexible. In either case,
the array class(es) should be created as templates so that the base
element type is variable. See the "vector" class in the STL or the
"CArray" class in MFC for examples of array templates.
Records:
Simple records can be mapped irectly to structs or public classes.
Variant records can be simulated using tagged unions or with a class
heirarchy depending on your needs.
Keep in mind that C++ has no equivalent of "WITH <blah> DO" - all
struct/class member accesses must be unambiguous or fully qualified so
you need to decide how to handle that.
I forget whether ISO allows files in records. An object based
implementation will be easier as GET/PUT will have do the right thing
for all your record types.
Files:
I/O in C++ is nothing like Pascal [even forgetting about files in
records]. C++ I/O is stream based while Pascal is record oriented.
You can easily simulate GET/PUT behavior for simple types and for
arrays/structs based on simple types, but you cannot simply write or
read objects.
Your equivalents of PUT will need to recognize an object and store the
object type and data in a way that allows the object to be
reconstructed on the fly when GET reads it back. This is called
"serialization" and in C++ it requires "run time type information"
[RTTI] and some fairly advanced coding techniques.
FOR Loops:
Pascal specifies that the number of iterations of a FOR loop cannot be
modified by the body of the loop [GOTO and . Implementations handle
that variously by disallowing assignment to the loop index variable or
by using a hidden loop index counter.
The "for" construct in C++ does not have this property - it is simply
syntactic sugar for the equivalent "while" loop. All uses of FOR in
the Pascal program must be checked and rewritten if necessary to
ensure the iteration count is accurately maintained.
It's been too long since I did any serious coding in Pascal so there
are probably a hundred other nit-picking things that will plague you
in translation that I can't think of just now. Good luck.
George
========================================
=====
ex: function objects
procedure foo( x: integer; y: var integer );
var z;
procedure in_foo( w: integer );
begin
y := w+z;
end;
begin
z := 2;
in_foo( x );
end;
can become something like:
class _foo
{
private:
int* yref;
int z;
void in_foo( int w );
public:
void operator()( int x, int &y );
};
void _foo::operator()( int x, int& y )
{
yref = &y;
z = 2;
in_foo( x );
}
void _foo::in_foo( int w )
{
*yref = w + z;
}
which is used like so:
main( ... )
{
_foo foo;
int y;
foo( 1, y ); // y := 3
}
Overloading the "()" operator allows you syntactically to use the name
of the object variable directly as a function name. For an automatic
translation tool it would be easiest to put all of the top level
parameters and all of the local variables into the object instead of
picking and choosing as I did here.
The example can be extended recursively to handle the case where
in_foo had further nested routines - just make an _in_foo class and
declare object "_in_foo in_foo" as a member of class _foo.
etc., ad nauseam.
========================================
=====
| |
|
| How do you want to handle maintenance? Do you want to do all
maintenance on the original Pascal code, and re-convert as needed, or
do you want all maintenance to be done on the new language?
Converting legacy Pascal code to an OOP language is going to leave you
with a very poor object model, non-optimum in every way. It may "work",
but that code can't be maintained directly.
Regardling procedural parameters, the .NET CLR supports delegates,
which are strongly typed pointers to functions. I always thought Pascal
was strongly typed until I started working with .NET - they've taken it
to the next level. You can't cast a delegate to make it point to an
incompatible function, which is definitely possible in Delphi. Anytime
you cast in .NET it has to be a cast to a compatible type, or you'll
get a runtime exception.
I *STRONGLY* recommend the book, "Compiling for the .NET Common
Language Runtime" by John Gough. A lot of people overlooked this book
because they didn't understand why it's so good. John ported a Pascal
compiler to the CLR and this book is about what he learned along the
way (by the way, this Pascal compiler is high quality and open source,
so you don't really need to convert your code in the first place).
John covers the details of the CLR as a target platform of a compiler,
and much of the book is not in any way specific to Pascal. He covers
the various ways to target the CLR by generating ilasm code, or by
emitting the code directly. John is brilliant and I read everything I
find with his name on it.
Another book that gets overlooked is "Compiling with C# and Java" by
Pat Terry. This is also great for explaining how to target the CLR from
a compiler. If you live in the US you have to order this from amazon in
the UK, since it's not available in the US.
Eric
| |
| Martin Ward 2006-04-08, 7:03 pm |
| On Monday 03 Apr 2006 06:39, Steve wrote:
> 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.
Have you looked at p2c, a Pascal to C translator:
http://directory.fsf.org/p2c.html
"P2c is a tool for translating Pascal programs into C. The input consists of a
set of source files in any of the following Pascal dialects: HP Pascal,
Turbo/UCSD Pascal, DEC VAX Pascal, Oregon Software Pascal/2, Macintosh
Programmer's Workshop Pascal, Sun/Berkeley Pascal, Texas Instruments Pascal,
Apollo Domain Pascal. Modula-2 syntax is also supported.
"Output is a set of .c and .h files that comprise an equivalent program in any
of several dialects of C. Output code may be kept machine and
dialect-independent, or it may be targeted to a specific machine and compiler.
Most reasonable Pascal programs are converted into fully functional C which
will compile and run with no further modifications, although p2c sometimes
chooses to generate readable code at the expense of absolute generality."
--
Martin
martin@gkc.org.uk http://www.cse.dmu.ac.uk/~mward/ Erdos number: 4
G.K.Chesterton web site: http://www.cse.dmu.ac.uk/~mward/gkc/
| |
| Neelakantan Krishnaswami 2006-04-08, 7:03 pm |
| Steve wrote:
>
> 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++.
There are relatively straightforward ways to compile these, but they
are generally fairly annoying to do, and not a good idea if you hope
to maintain the translated source rather than use C++ as a target
language.
> 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.
>
> We also have a few instances of Pascal procedural parameters. Can
> these be emulated?
Both of these can be very easily translated to C# using delegates,
which is what C# calls first-class functions.
--
Neel Krishnaswami
neelk@cs.cmu.edu
| |
| thompgc@gmail.com 2006-04-08, 7:03 pm |
| There are now versions of Delphi that support .NET
Perhaps you could compile the Delphi code you can already generate
w/one of those versions and used the resulting .NET assembly in Visual
Studio.
Or you could use .NET version of Delphi on some of the constructs that
are giving you trouble and see what .NET IL they generate. Perhaps
that would then give you an idea how to generate the code.
| |
| Marco van de Voort 2006-04-09, 7:06 pm |
| On 2006-04-08, John O'Harrow <john@elmcrest.demon.co.uk> wrote:
> Converting from Delphi Object Pascal to C# should be much easier than
> converting to C++. The Delphi and C# languages are very similar (Anders
> Hejlsberg, the lead C# architect at Microsoft was the main developer of
> Delphi in its early days).
I doubt it. While the high level aspects of the language are closer to C#,
the lower level aspects are closer to C/C++.
And in C/C++ it is easier to emulate the highlevel Pascal constructs than it
is in C# to emulate the lowerlevel features.
Keep in mind that Delphi allows e.g. pointer arithmetic, inline
assembler and pearls like overlaying a variant record over a calculated
pointer will be pretty hard to emulate in C#.
| |
| Marco van de Voort 2006-04-09, 7:06 pm |
| On 2006-04-08, Eric <englere.geo@yahoo.com> wrote:
> I *STRONGLY* recommend the book, "Compiling for the .NET Common
> Language Runtime" by John Gough. A lot of people overlooked this book
> because they didn't understand why it's so good. John ported a Pascal
> compiler to the CLR and this book is about what he learned along the
> way (by the way, this Pascal compiler is high quality and open source,
> so you don't really need to convert your code in the first place).
Note that if that is about Gardens Point Component Pascal, CP is a successor
to Oberon-2 to my knowledge, and has been geared towards portability (ported
to JVM too) and thus is pretty much a long way from a typical native
production Pascal dialect, that invariantly got some C features for OS
interfacing?
A better reference for production code could be simply investigating what
docs Borland has about .NETifying Delphi code to compile under Delphi.NET.
What works, what not, and then make an invetarisation of what constructs
| |
| Marco van de Voort 2006-04-09, 7:06 pm |
| On 2006-04-08, George Neuner <gneuner2@comcast.net> wrote:
> Nested Routines:
> Simulating nested routines is fairly simple - you turn the top level
> function or procedure into a C++ "function" object - that is an object
> that overloads the call operator "()". You convert the shared local
> variables and top level parameters to member variables and any nested
> routines into member functions [or recursively, into member function
> objects]. See example below.
I quickly looked over it, but I don't fully get it. Is this supposed
to be a general solution (e.g. also for call pattern that might be
more complicated than parent ->1st level child -> 2nd level child) ?
I've seen complete recursive descent parsers as nested procedures.
> Records: Simple records can be mapped irectly to structs or public
> classes. Variant records can be simulated using tagged unions or with a
> class heirarchy depending on your needs.
Variable size instantiation of pointers to variant records might be fun :-)
new (x,true,false)
will create a ptr to a record with size that matches when the "true" branch
of the first level of the unit is taken, and the "false" branch nested in
there. Note that this ISO feature doesn't exist in the Borland lineage.
> Your equivalents of PUT will need to recognize an object and store the
> object type and data in a way that allows the object to be
> reconstructed on the fly when GET reads it back. This is called
> "serialization" and in C++ it requires "run time type information"
> [RTTI] and some fairly advanced coding techniques.
(note that serialisation can also be done using simple inheritance and
writing each field individually. RTTI is only necessary if you want to avoid
spelling out the fields, and don't need the extra control to specify the
fileformat)
| |
| Hans-Peter Diettrich 2006-04-10, 4:09 am |
| Eric wrote:
> Regardling procedural parameters, the .NET CLR supports delegates,
> which are strongly typed pointers to functions. I always thought Pascal
> was strongly typed until I started working with .NET - they've taken it
> to the next level. You can't cast a delegate to make it point to an
> incompatible function, which is definitely possible in Delphi. Anytime
> you cast in .NET it has to be a cast to a compatible type, or you'll
> get a runtime exception.
Can you please explain your Delphi specific statement?
Delphi has procedural types, for both ordinary procedures and methods,
with according compile time checks, so that runtime checks are not
required. There exist very few ways (and needs) to fool the compiler,
which exist in every language or compiler, which support unchecked type
casts or unmanaged code (for portability reasons). In addition Delphi
distinguishes .NET from Win32 code, so that it's not clear whether you
address the .NET or Win32 compiler of Delphi, and whether or not it's
possible to turn off support for legacy syntax and semantics. I'm only a
Delphi for Win32 user, therefore my ignorance and questions about the
..NET compiler...
DoDi
| |
| George Neuner 2006-04-10, 4:09 am |
| On 9 Apr 2006 17:25:00 -0400, Marco van de Voort <marcov@stack.nl>
wrote:
>On 2006-04-08, George Neuner <gneuner2@comcast.net> wrote:
>
>
>I quickly looked over it, but I don't fully get it. Is this supposed
>to be a general solution (e.g. also for call pattern that might be
>more complicated than parent ->1st level child -> 2nd level child) ?
It is a general OO solution for simulating statically scoped nested
functions using top-level functions plus statically scoped data.
By turning parameters and locals of the enclosing function into object
data members, you provide the scope chain which enables the "nested"
functions - implemented directly as object member functions or as
additional "function object" members - to access the data scope of the
enclosing function.
>
>(note that serialisation can also be done using simple inheritance and
>writing each field individually. RTTI is only necessary if you want to avoid
>spelling out the fields, and don't need the extra control to specify the
>fileformat)
RTTI is not required to implement serialization, but it makes certain
aspects of [in particular] unserialization easier when dealing with
heterogeneous containers or multiple inheritence.
George
| |
|
| First, let me say that I love Delphi and I would not want to start a
"Delphi vs C#" kind of debate here. They are both good, and they have
differences. The question about strongly typed cast checking at
runtime is not really a language issue - it's more of a platform
issue. The Win32 platform can support runtime cast checking, but you
don't see this in most popular Win32 languages because of efficiency
concerns.
Delphi for Win32 is more like traditional C in the way it handles
casting. The type compatibility is determined at compile time. Once it
passes the compiler test, there is typically no runtime code to
validate the cast. I know they have some runtime checking, but this is
not normally used on objects at runtime to determine if a cast is
valid. The cast normally does not exist in the runtime code - there is
only limited runtime validations for things like array bounds. You can
typically cast just about anything to a pointer, and use it as you
wish. I'm not trying to slam Delphi here - the way it does this kind
of code makes it very efficient. Delphi borrowed pointer handling from
C in a general sense.
..NET, like Java/JVM, does have a special instruction that is used at
runtime to validate a cast, and it throws a runtime exception if the
cast fails. Java doesn't have the same kind of delegates (function
pointers), but Java deserves credit for the concept of a runtime cast
validation. Of course it may have originated elsewhere, but Java made
it a popular idea.
Delphi for .net has first-class support for strongly typed delegates,
and Delphi supports most CLR functionality. It also excels at "unsafe"
code that runs under the CLR for cases where you need to break the
rules on purpose. Only C++ and Delphi can do a good job with "unsafe"
CLR code. C# is terribly bad at this, and they intentionally made it
hard to do because they didn't want to encourage unsafe code.
The only reason I didn't recommend Delphi for the original poster is
that he has a ton of legacy non-OOP Pascal code. This kind of code
can't be automatically translated into ANY OOP language in a good and
maintainable manner. So his best bet might be to stay with legacy
Pascal (perhaps with Gardens Point Component Pascal, which handles OOP
and non-OOP code AFAIK), and migrate to a true OOP design by
hand-coding new routines over a period of years.
I'm also somewhat concerned about Delphi's future in regards to their
impending spinoff from Borland. It won't die anytime soon, but it has
a black eye, and may get beat up a bit more. This is  because the
fine lady deserves better.
Eric
| |
| Waldek Hebisch 2006-04-12, 10:02 pm |
| Steve <steve@rh12.co.uk> wrote:
> 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#. 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.
>
> So the question is which language to use? I know C++ a little, but the other
> two are new to me.
>
> 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++. 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.
>
> We also have a few instances of Pascal procedural parameters. Can these be
> emulated?
>
> Fortunately no-one ever used conformant arrays. :)
First, you should decide your objective. If the goal is to link
together code in Pascal and C++ then GNU Pascal may do it: GNU Pascal
support all ISO 7185 constructs and most of ISO 10206. GNU Pascal uses
code genarator from GNU C and offers special types for C
interfacing. ATM GNU Pascal still does not support some esoteric
Extened Pascal (ISO 10206) features but there is good chance that it
can compile your program without changes.
You can also use Delphi to compile both Pascal and C++ (but you wrote
that you need to covert your code to make it acceptable to Delphi).
If you _must_ deliver as .NET then you can still use Delphi (GNU
Pascal generates only native code).
If you want to convert source once and continue development on
converted version then problem is more tricky. First, it is definitely
easier to convert taking C as a target language then to other
languages (but the result is likly to be .NET unfriendly). In general
it is hard to get both correct and readable code after conversion. For
ISO 7185 Pascal old p2c is likely to do good job. Beware that if your
code contains errors or constructs beyond what p2c can handle then p2c
may crash or silently generate wrong output. As long as you give it
good input p2c works quite well.
If p2c can not handle your program you may still get hints from code
p2c generates: it handles nested procedures introducing special
records to gather variables from parent routine and passes its address
as an extra parameter (this technique is slower then other, but quite
general).
If you have nested procedures as procedural parameters then you need
to add extra parameter to all routines that are passed to the same
procedural parameter as the nested procedure (and then repeat adding
extra parameter until you reach a fixpoint). In other words, treat
nested procedures as a new type and promote non-nested procedures to
this new type as long as needed to make program type correct.
Non-nested procedural parameters can be easily translated to function
pointers in C/C++.
--
Waldek Hebisch
hebisch@math.uni.wroc.pl
| |
| Oliver Bandel 2006-04-14, 7:07 pm |
| Steve wrote:
> 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.
ooops. :(
Then you might use F# ?
It's an (incomplete) OCaml port for M$.
http://research.microsoft.com/fsharp/fsharp.aspx
Some things might look a littlebid pascal-like,
so porting might be easier than to the ugly languages
from the C-family.
> 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#. ...
There should be similarities in the constants-thing I think.
> So the question is which language to use? I know C++ a little, but the other
> two are new to me.
C++ is ugly.
If the OCaml-port to M$ was not too bad then you should use this.
> So far the main obstacle I can see with C++ is the nested routines of
> Pascal.
What do you mean with nested routines? Example?
Do you mean (mutual) recursion or what?
> I don't know of any way to do this in C++.
you might explain what you mean...
....maybe you can write it in C++ in a different way.
But I would not say use C++ as you has seen I
would use ifferent languages.
> 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.
In Ocaml you can create types like this one:
type my_type = A of int | B of char | C of string
I think F# should do it similar.
And then you have pattern matching and that stuff, which
makes programming really a fun! :)
>
> We also have a few instances of Pascal procedural parameters. Can these be
> emulated?
example?
I once did some Pascal programming but it's a while ago and
I'm not as experienced with it like in C or Ocaml.
example-code?
>
> Fortunately no-one ever used conformant arrays. :)
unknwon term "conformant array".
Explanation for an not-so experenced Pascal-programmer?
Ciao,
Oliver
|
|
|
|
|