Symantec Top 10

By Craig Conner

This month we start with a few THINK Pascal questions, then run through questions dealing with exception handling (or lack thereof), and then finish off with some miscellaneous topics.

The first question is from a news post:

Q: I have a large THINK Pascal project that I have always compiled for 68K with a floating-point unit. I now want to compile for a 68030-based PowerBook that has no FPU. Unfortunately, I am having some problems linking. If I turn off 68881/68882 under Code Generation in the Compile Options dialog, I get a link error:

undefined: 3SINH2 (Activation.p)

undefined: 3TANH2 (Activation.p)

I need to use these functions but I do not know how to get rid of this error. I did remove the SANELib881.lib library and replace it with SANELib.lib, but I still get the error. Any suggestions?

A: Unfortunately, those functions are defined in SANE.p only if you are compiling with 68881/68882 on. Fortunately, here are sinh, cosh, and tanh defined:

 function SinH(x:real):extended;
 begin
 sinH:=(exp(x) - exp(-x))/2;
 end;

 function CosH(x:real):extended;
 begin
 cosH := (exp(x)+exp(-x))/2;
 end;

 function TanH(x:real):extended;
 begin
 TanH := SinH(x)/CosH(x);
 end;

 TanH can be optimized like this:

 function TanH(x:real):extended;
 var
 eToX, eToNegX:extended;
 begin
 eToX := exp(x);
 eToNegX := exp(-x);
 TanH := ( eToX - eToNegX ) / (eToX + eToNegX);
 end;

It will be a tad slower than using SANE, but it will work. You can look at how exp(x) works on p. 358 of the THINK Pascal Users Manual, and the hyperbolic functions in any trigonometry textbook.

Q: When using THINK Pascal, I want to create my own pattern for use with the PenPat routine. How do I do this?

A: You should use the StuffHex routine (QuickDraw) to build your patterns. StuffHex will interpret its argument as an 8-by-8 bit-pattern with 1’s denoting “on” bits, and 0’s denoting “off” bits. Like so:

var
 myPat :Pattern;

StuffHex(@myPat, 'FFFFFFFFFFFFFFFF'); {All on}

Q: In THINK Pascal, whenever I try TextFace(bold), I get an “incompatible type” error. Why?

A: The “styles” used in Pascal are values in a set and need to be expressed as [bold], [underline], [italic], etc. Normal text is specified as the empty set, []. Try:

TextFace([bold]);

Q: In a TCL project that I am updating to version 8.1, I get an “undefined” error on catch_. What might cause this?

A: If you are using native exceptions (which is standard for 8.1 projects), catch_ has been redefined as catch_reference. Here is an example:

try_
{
   DoIt();
}
catch_reference(CException, e)
{
   errVal = e.GetErr();
}
catch_all_()
{
   errVal = -1;
}
end_try_

Q: I have just completed my latest project using TCL, and want to use MrC++ for the finishing touch. However, I get link errors when trying to build it. Why?

A: MrC and MrC++ do not have native exceptions built in, so you need to change the libraries some to get your project to link correctly. Remove the current CPlusLib TCL.o and BRLib libraries, and replace them with the ones that use the non-native exception handling. These are CPlusLib TCL_BELeh.o and BRLib(non-native eh).o. That should get it working.

Q: I just saw a note in the fp.h header recently about dtox80 and x80tod being contained in a library called MathLib v.2. Why was it not included on the last CD?

A: That note in the header file is premature. Apple has not released a new version yet. Currently you can use ldtox80 and x80told and they will work correctly.

Q: While compiling the OpenDoc project ODFFramewrk.RB.Π I get “not enough memory” errors when trying to load the precompiled header called ODFHeaders.RB. How can I fix this?

A: The obvious answer is to get more RAM. OpenDoc will require at least 32 megs, and the more the merrier. Turning on Virtual Memory should also work, but will slow compiling down. If Virtual Memory is too slow, you can change the size of the precompiled header using a switch set up for the headers. In the ODF.pch file, there is a:

#define FW_AGGRESSIVE_PRECOMPILE 1

Change this to 0 and then do the same for FWEnvDev.h. After re-precompiling, the ODFHeaders.RB file will be smaller.

Q: I am trying to build a 68K version of one of my SPM projects. I get the following error at link time using Link via ToolServer:

A: There are some nuances that you need to take care of when using ToolServer to link a 68K application in the link order file (the .lo file). The MPW68KRuntime library uses Near code, so it needs to be near the top of the list (in one of the first two segments that get created). Also, since that library calls the main routine, the file that contains that routine needs to be near that library. If you get a similar error after rearranging, then you need to turn on Far Code in the linker options, and use Far libraries where possible. Any library that does not have a Far version (like the runtime lib) needs to go near the top of the list.

Q: When using the alloc_gla memory package with the Vector demo, it reports heap corruption. What is wrong with the example?

A: Looking at the example, we see code like this:

    vector(int size)   { v = new T[size]; sz = size; };
    ~vector()          { delete v; };

This code may have been correct at one time, but nowadays it is not. Since the new call allocates an array, the delete operator is no longer the proper operator to use. Instead, the delete[] operator should be used, and alloc_gla will stop complaining:

    vector(int size)   { v = new T[size]; sz = size; };
    ~vector()          { delete[] v; };

Q: If I realign a structure like so:

#pragma options align=mac68k
struct{
...
}myStruct;
#pragma options align=powerpc 

my program crashes when trying to use myStruct. What might be happening?

A: The default setup for PPC projects is to use four-byte boundaries. align=powerpc will align to two-byte boundaries, and could cause incompatibilities. Use #pragma options align=reset instead, and that should fix the problem.