lanceboyle@bluebottle.com wrote:
I tried posting this to the Mac Pascal (Pascal Central) list but for some reason it is not making it.
Are you using mac-pascal@listman.sonic.net for the MacPascal mailing list address? A while ago Bill Catambay the list owner made the slight "-" change to the mailing list address in an atempt to dodge SPAMmers who had latched onto the previous address.
If you are using that address, you might want to contact Bill Catambay directly through the Pascal Central support form at http://excaliburworld.com/support.html to see what the problem might be and get some direct assistance on resolving the problem.
===============================
I might be confused about how to import math functions in GPC.
GPC itself doesn't seem to have the functions that I need (I'm looking in gpc.pas), but in the docs there is a mention of math.pas. However, I can't find such a file in my GPC installation.
Do I need to use (non-portable) Mac math libraries?
It depends upon which Mac math libraries routines from fp.p your existing code is using. While GPC does add a few math function to the standard Pascal language package one had when using Metrowerks/CodeWarrior Pascal or THINK Pascal, GPC does't provide direct support for the full set of routines in fp.p.
If so, is fp.p still the preferred interface?
Yes. However, I'll note the file name for the GPC compatible fp unit is fp.pas.
In the case of more common functions such as trig stuff, does fp.p override the Pascal built-ins? Or conflict with them?
If you use (or import) the fp unit, the fp routines will scope hide/override the Pascal language built-ins. I will note with the GPC version of the fp unit interface, the previous declaration conflicts between fp and standard Pascal for round and trunc have been fixed by renaming the respective fp routines to roundd and truncd. (Note: Even though they are renamed at the Pascal language level, GPC fp.pas declares them in a manner so that they still link to the correct Apple supplied library function.) If your existing code made use of fp's round and trunc implementations and relied upon scope hiding to hide the Pascal language built-in round and trunc, you'll need to make some code changes to keep things working correctly.
Although fp's round and trunc were renamed in the GPC version of fp.pas, I'll note that it wasn't really necessary to do so. GPC supports several Extended Pascal languages features which aren't supported by Metrowerks/CodeWarrior Pascal or THINK Pascal to handle name conflicts like this. Depending upon the version of GPC you're using, selective "only" imports, import renaming, qualified imports, and function/procedure block level versus unit/module block level importing are in the supported toolkit to handle this type of conflict. In case it isn't readily obvious, these language features also give you a quite a bit of flexibility in choosing between whether your code uses the Pascal built-in implementation or the Apple library supplied implementation of the common functions.
I believe that pow() is a problem with respect to conflicts and I see that some headers seem to note this in a compiler directive.
Frank Heckenbach wrote:
Well, pow is an operator, not a function, in Extended Pascal. But as long as you don't use strict EP mode, GPC should allow overriding it with a function. (BTW, what kind of compiler directive?)
{$disable-keyword=pow} is the compiler directive. When fp.pas was first ported for GPC use, I believe that directive was necessary to get the unit to compile. Since that first port, GPC has undergone some pretty extensive changes in this area so I'm not sure whether that directive is still needed.
lanceboyle@bluebottle.com wrote:
Also, I see that floating point types Double and Real are the same and eight bytes, while Extended and LongReal are 16 bytes--is that correct? To make old code work that assumed that Extended is eight bytes, can I write type Extended = Real without my computer exploding?
Instead of rolling your own type size specific master type declarations, I suggest you use the master sized type declarations in MacTypes.pas as long as you're working with Mac OS [X] code. In using MacTypes.pas master types, type size issues like this one have already been addressed by the maintainers of the Mac OS [X] interfaces and the compiler appropriate declaration needed to yield the specified type size is already there in the interfaces for the presently supported FPC, GPC, and Metrowerks/CodeWarrior Pascal compilers and architecture targets and will be there for any future supported compilers and targets such as GPC Mac OS X Intel. For this particular case, the MacTypes.pas Float64 type will alyways result in an eight byte sized floating point type regardless of whatever sizing quirks there might be with the built-in types for the compiler you're using or the architecture you're targetting.
Gale Paeper gpaeper@empirenet.com