Visual Basic

[wareagle]

I have several electrical programs written in Turbo Pascal.
I want to rewrite these and was thinking of using Visual Basic. I need pointers and pointer records. Is this the proper package to do this? I haven't written using VB before.

 

[FrancisL]

It should be vastly easier than Turbo Pascal, apart from the learning curve.
For pointers and pointer records you have a large choice - VB has Arrays of many sorts, or probably better you can use a database to store your data.

 

[scottydoesntknow]

wareagle,
FrancisL is right, you might want to use a database of some sort with VB. You CAN use pointers in vb, but the method is a little bit of a hack and not really necessary unless you are sorting objects of moderate size. vb should be relatively easy for you to pick up if you have any programming experience at all. Just be careful, unless you are using .NET, the older vb's have some interesting quirks...

 

[nbucska]

I think "C" would be easier.
Can you describe the problem and perhaps E-mail the program ?


<nbucska@pcperipherals DOT com> subj: eng-tips

 

[hdingman]

If you know pointers in C, you DON'T know pointers in VB. Bluntly, it's difficult to use pointers in VB, and I've had a lot of problems with memory leaks trying to use pointers and SET POINTERNAME=NEW(OBJECT) / SET POINTERNAME=NOTHING. For linked lists and insertion sorts, VB is OK, but don't try to do high-speed calculations indexed into the record.

Translating from Pascal to C/C++ is not difficult, and will probably have a lot less headaches if you use them rather than VB. They two languages are so similar that there are several "PAS2C.H" files filled with "#define"s that can (crudely) make Pascal source compile on a C compiler. There are plenty of test tools to write a good clean fast routine and debug it.

VB's overhead to get to storage is a lot more than C, and VB also does nasty things like word-alignment in a record without telling you. If you try to use "real" pointers into a record, you can get into trouble fast.

C has "real" pointer types, VB does not. VB records and pointer records are a comprimise at best. VB record processing together with opening a database adds a LOT of system overhead. If you're using pointers to create work-in-process results, then do you want them in nanosecond-access RAM or millisecond-access database disk storage? If performance is an issue, I would (and do) use C. If the calculations are repetitive and you want to store/lookup rather than recalculate results, then VB-over-DB is probably fine.

If your program is a simple formula calculator, type in some values and get a result, then VB is an easy language to rewrite your program. When repetitive or reentrant engineering calculations make VB unbearably slow, move to C/C++. Or, just save the headaches and start in C.

So... What's an "electrical program?" Are you calculating and balancing dynamic loads on a power grid, or solving resistance values in Ohm's law?

Howard

 

[someonesdad]

One option is to not translate it at all. I haven't used it, but the MinGW distribution comes with a Pascal compiler (IIRC, it might be an early version). I used MinGW as my default C/C++ compiler on my Windows 2000 box. Check out

http://www.mingw.org/.

Also, a Pascal to C translator program called p2c has existed for many years. Check out e.g.

http://packages.debian.org/unstable/devel/p2c.html.

One advantage of VB is that you can quickly come up with forms and an application. That may make it worth the effort, but you'll likely have to rewrite your app from scratch. You don't say whether it's a console program or a Windows program (likely a console program if done with Turbo Pascal). I frankly have to admit I was seduced by VB6 a few years ago and decided to translate a C app I had written into VB. I ultimately had numerous problems, one of which was a crashing application after installing a service pack. I finally dumped VB in disgust. While it's definitely capable of producing useful applications, your knowledge and effort of learning the thousand and one details aren't transferable to another system. From that standpoint, using a language like C++ makes more sense (of course, every language comes with some kind of baggage...).