Xref: utzoo comp.software-eng:1644 comp.lang.pascal:1958
Path: utzoo!utgpu!watmath!maytag!watstat!dmurdoch
From: dmurdoch@watstat.waterloo.edu (Duncan Murdoch)
Newsgroups: comp.software-eng,comp.lang.pascal
Subject: Re: Borland's Object-Oriented Pascal--is it worth it?
Keywords: borland pascal object oriented
Message-ID: <267@maytag.waterloo.edu>
Date: 19 Jun 89 12:48:36 GMT
References: <2048@orion.cf.uci.edu> <5534@rpi.edu>
Sender: daemon@maytag.waterloo.edu
Reply-To: dmurdoch@watstat.waterloo.edu (Duncan Murdoch)
Organization: U. of Waterloo, Ontario
Lines: 40

In article <5534@rpi.edu> mcintyre@cs.rpi.edu (David McIntyre) writes:
>Robert Morey writes:
>>
>>   [ Robert is worried about upgrade problems to TP 5.5 from 4.0]
>>
>
>The upgrade to 5.5 should be almost non-existant.  The change from 5.0
>to 5.5 is comprised of 4 new keywords: object, virtual, constructor,
>and destructor.

The second part is not quite true:  there are a few more changes than that.
Most are extensions to the 4/5 syntax, so should present no problems.
These include changes to the New and Dispose procedures, and the addition
of a new Typeof procedure.

One change that did cause me some trouble is that the signature that gets put
into a TPU to tell the compiler whether it needs a new version has become
more picky.  In the Turbo Professional package, there's a unit (TPSTRING) 
that depends to a very small extent on whether the N+ flag is set. (It
affects the float type that gets converted to a string.)  Many units use
this unit.  I used to be able to keep two versions of TPSTRING, 
one compiled N+ and the other compiled N-.  I didn't need two versions of 
any unit that Use'd TPSTRING, unless it too depended on the N+ flag.  Now
in version 5.5 I do.  

I'm still not sure whether it was a bug in version 5.0 that let
me get away with what I was doing, or whether version 5.5 is being 
unnecessarily picky.

One change that seems to be a welcome relief is that (at last) the code
generator for Extended math seems to make efficient use of the coprocessor
stack.  It used to be that an expression like

  a := b+c+d+e+f+g+h+i+j+k+l;

would overflow the stack if all the variables were extended; this bug has
thankfully been fixed now.  For anyone translating numerical routines written
in Fortran, this alone would be worth the price of the upgrade.

Duncan Murdoch