"steven.borley" wrote:
On 20 Feb 2005, at 18:37, Waldek Hebisch wrote:
The simplest solution is to rename `round' from fp.pas on import like: import fp (round => fp_round);Yes, that works for a simple test program.
Which gives me another problem. I've never used 'import' before, just 'uses'. Looking at the GPC manual, 'import' can only be use in a program file not a unit/module. This is rather limiting for me, if true, as my problem code is spread around several units.
Although I haven't tested it with the latest versions of GPC, I have in the past used Extended Pascal's renaming feature in a uses clause so "uses (round => fp_round)" is alternative to try if you prefer uses clauses to import specifications.
Another thing. I noticed is that trunc() has been renamed to truncd() in fp.pas and there is a comment on the microbizz site (http://www.microbizz.nl/gpcdiffs.html) that says this...
<quote> 11.��� Trunc
In ISO Pascal Trunc is a predefined function that returns an integer value. It is an error if the result value of Trunc doesn't exist in the Integer type. The fp.pas unit of Apple�s PInterfaces declares a trunc function that returns a value of type Double_t.
To solve this ambivalence, the trunc function in fp.pas has been renamed to truncd.
</quote>
So this looks like the same problem as I have with Round(), but with a different solution. So I'm now beginning to think think this is a GPCPInterfaces bug (or at least inconsistency). Should round() in fp.pas not have been renamed roundd() for the same reasons?
It is more of an inconsistency than anything else. It is more or less a case of six of one and a half a dozen of the other of which method to use to resolve the name conflicts. Either way, in order to use GPC's ISO Pascal round and trunc in the same scope as fp's round and trunc, fp's round and trunc have to be renamed either the GPCPInterfaces's declarations or with a renaming clause on using/importing them into a unit or module where one wants to use them in the same scope as ISO Pascal's round and trunc.
Regardless of how the GPCPInterfaces fp inconsistency is resolved, I don't think there is anyway to resolve the name conflicts between Apple's fp API and ISO Pascal's predefined functions in a manner which will work transparently for GPC and Metrowerks/CodeWarrior Pascal common source code usage. (There is a linker error/bug in corresponding MWPInterfaces fp using truncd instead of trunc so don't rely upon that as the correct way to handle the conflict with Metrowerks/CodeWarrior Pascal.) So, if you want the capability of compiling your source code with both compilers use conditional compilation tests on __GPC__ and MWERKS to handle to compiler specific means of resolving the conflict.
Gale Paeper gpaeper@empirenet.com