Jan 94 Top 10
| Volume Number: | | 10
|
| Issue Number: | | 1
|
| Column Tag: | | Think Top 10
|
Think Top 10 
By Kevin Irlen, Think Technical Support, Symantec Corp.
Note: Source code files accompanying article are located on MacTech CD-ROM or source code disks.
This is a monthly column written by Symantec’s Technical Support Engineers intended to provide you with information on Symantec products. Each month we cover either a specific application of tools or a “Q&A” list.
Q. I’m trying to compile a simple “Hello World” example in C++, and I get an “invalid declaration” on a line that reads “class ostream;” in file <2comp.h>. What’s going on, and where did this file come from?
A. You’ve #includ’ed <iostream.h>, but by reflex, you must have created a .c file... Since the default translator for .c files is the C translator, <iostream.h> just ain’t gonna compile. The first place it violates C syntax is in the indicated line in <2comp.h> which <iostream.h> #include’s. Until you realize what’s going on here, this can be pretty confusing! Save your file as a .cp file, and this problem should disappear.
Q. How do I send my output to the printer using IOStreams? And I just want specific output to go to the printer, not my users’ prompts and responses.
A. IOStreams works on top of the Standard Library console package, so cin is tied to stdin, cout to stdout, and cerr to stderr. To echo stdout to a file or to the printer, you still use cecho2file or cecho2printer. With the Standard Library console package, separating output from the main console means simply creating another console, using fopenc. The strategy is the same for IOStreams, the only trick is tying the new console to a stream. This is done via a stdiobuf, as illustrated below:
/* 1 */
#include <console.h>
#include <fstream.h>
#include <stdiostr.h>
void main(void)
{
FILE *fp = fopenc();
stdiobuf fps(fp);
ostream os (&fps);
chide (fp);
cecho2printer(fp);
os << "This goes to hidden console & the printer" << endl;
cout << "This goes to the user." << endl;
}
Q. I’m trying to override the global operator new. But I get “multiply defined: operator new(unsigned int) (myfile.cp, CPlusLib)”. What should I do?
A. There is really no such thing as “overriding” global operator new. You can overload it by supplying a function which takes additional arguments beyond the required size_t first argument, and you can provide a class with its own operator new; but if you want to replace the global operator new(size_t) that is defined in CPlusLib, then you’ll have to do just that -- replace it, and have your own custom CPlusLib. (In other words, as far as the linker is concerned, operator new is treated just like any other function.)
One interesting example of overloading global operator new is the “placement” operator new provided by <stddef.h>, which takes an additional void * argument and simply returns that same argument. The purpose of this function is to allow previously allocated storage to be used to hold a new instance of an object, while retaining the constructor-calling action of operator new. (Here again, if for some reason you wanted to “override” this function you would have to replace it.)
Finally, the confusion about “overriding” may come from the fact that you can override the “new handler” which is called when a memory allocation request can’t be met. This is done simply by calling set_new_handler with a pointer to your “new handler” function.
Q. I have an abstract class with all pure virtual functions, including the destructor. I do not define any of these functions, since they must be overridden in a derived class. However, a get a link error telling me the abstract class’ destructor is undefined. What’s going on?
A. Virtual destructors insure that the appropriate destructor gets called first for an object whose class is not determined until run time.
/* 2 */
class A
{
virtual ~A();
...
};
class B : A
{
~B();
...
};
void main(void)
{
A *a;
...
a = new B;
...
delete a; // B's destructor called first.
...
}
They do not change the fact that destructors are then called for each base class when the derived class object is being destructed. Declaring a destructor pure virtual does not change this fact either. The pure specifier here, as with any function, forces the class to be abstract, and forces the derived class to define a destructor of the same type; but unlike with “regular” functions, it does not, and cannot bypass the need for the abstract class’ destructor actually to be able to called.
Q. All I did was add IOStreams to Starter++.Π and I’m crashing before I get to through application initialization.
A. IOStreams allocates memory during static initialization. The default 200K partition used by the Starter project will no longer be sufficient. Increase it to 300K, and the problem should disappear.
Q. Do libraries’ “Set Project Type” settings have to match the project’s “Set Project Type” settings exactly? Especially, what about Far Code and Far Data?
A. OK, here’s the whole deal...
Project Type: If the main project is an application, libraries must be applications as well. This is because globals and jumps are going to be referenced off of A5.
If the main project is not an application, libraries must be code resources. This is because globals and jumps are going to be referenced off of A4.
Partition: Libraries’ settings are ignored.
Size Flags: Libraries’ settings are ignored.
Separate STRS: If turned on in a library, the main project must be built with this option on as well.
(Separate STRS has no effect in C++.)
Far Code and Far Data: Some libraries explicitly test for these options, and compile differently based on their being on or off. Obviously, you would need to use the proper version of such libraries. The only THINK libraries that do this are oops and oopsDebug (and oops++ and oopsDebug++), and we provide oopsFar and oopsDebugFar pre-built (ditto for the ++ ones). For libraries that do not compile differently under different FAR or NEAR options, there is usually no need to build FAR versions of them in order to use them in a FAR project. However, as explained on pp.266-7 of the THINK User’s Guide, you should segregate NEAR libraries from the rest of your code. Finally, there are two cases where even segregating your NEAR libraries is not sufficient, and one or more of your libraries will have to be changed to FAR.
1) THINK must put all jump table entries of a NEAR CODE library into the first 32K of the jump table. Furthermore, if your NEAR CODE library calls out to a function in the main project (or in another library), then that function’s jump table entry must also be within the first 32K of the jump table. To provide a mechanism for this, THINK will create NEAR jump table entries for ALL functions in a segment containing a NEAR CODE library. Thus, a problem arises if your combined NEAR CODE libraries require more than 32K of jump table, or if, by putting other source files in the same segment as a NEAR CODE library, you cause the first 32K of the jump table to be used up before all the libraries’ NEAR entries can be placed: THINK will be unable to create enough NEAR jump table entries and you’ll get ILLEGAL NEAR REFERENCE link errors.
2) Similarly, THINK must put all global data referenced by a NEAR DATA library into the first 32K of the application’s global variable space. If a NEAR DATA library references external global data, then the file where the external data is defined must be in the same segment as a NEAR DATA library so its globals will also be stored in NEAR global variable space. Thus, a problem arises if the combined data of your NEAR libraries is greater than 32K, or if by putting other source files in the same segment as a NEAR DATA library you cause the first 32K of the application’s global variable space to be used up before all the libraries’ NEAR data can be placed: THINK will be unable to place all the NEAR DATA properly, and you’ll get ILLEGAL NEAR REFERENCE link errors.
In C++, all class vtables occupy global data space, so the FAR project/NEAR library problem can crop up if the library refers to classes that it does not define.
Q. We’re using SourceServer, and want to store our .rsrc files in the ProjectorDB along with our source files. As usual, SourceServer adds a ‘ckid’ 128 resource to each file, so we were worried that when we added the .rsrc files to a project we would get ‘duplicate resource’ errors when we tried to compile. But we don’t. Why?
A. If you take a look at the Resource Copier translator in ResEdit, you’ll notice that it’s got a ‘SKIP’ resource. This resource contains a list of resource types, which, as its name suggests, are to be skipped during resource copying. By default, it contains a single entry, ‘ckid’. (Yes, this means you could add other resources to the SKIP list; though I can’t think of a reason why you’d ever want to...)
Q. I’m running out of memory when running and debugging my C++ programs. Until I have more RAM, is there anything I can do to use the memory I have more efficiently?
A. First of all, make sure you understand what your memory situation looks like before compiling, and what it should look like once you’re successfully up and running under the debugger. For example, on a Mac LC III with 4Mb RAM things might look like this:
Before compiling:
System Software 1,100K
THINK Project Manager 2,048K
Free Memory 852K
After compiling, and running w/the debugger:
System Software 1,100K
THINK Project Manager 2,048K
Debugger 250K
Application 500K
Free Memory 102K
When memory is tight, you’ll have to strike a balance among these five pieces. Clearly you want your System to be as lean as possible. Keep in mind that during compilation the THINK Project Manager attempts to make the most out of your Mac’s memory, and the most efficient use of its own partition, by allocating out of the “MultiFinder temporary pool”, or free memory. Note that in the above example the TPM’s partition has been reduced from the 4Mb default to 2Mb, leaving about 100K free. This will produce better results than giving everything available to the TPM.
If you’re running out of memory while debugging, the solution is NOT to increase the Debugger’s partition. Even though you’re in the Debugger, it’s still the compiler that’s doing the work of evaluating expressions. Again, look to the TPM/free memory combination.
If you’re running out of memory before even getting into the Debugger, try holding down the option key while choosing Run. This resets the Debugger by clearing all expressions and breakpoints. Also, double-check that the partition you’ve set for your application isn’t greater than the amount of free memory!
Finally, here are two space/time tradeoffs that can help:
1) Don’t use precompiled headers. They improve compile time, but take up valuable space in the TPM’s heap.
2) By default, both the THINK C and Symantec C++ translators are kept in memory while the TPM is running. You can allow one or both to be swapped out, and save some space at the expense of speed, by tweaking a bit in ResEdit. Open the translator in ResEdit, and then open the ‘INFO’ resource. Scroll to the bottom and switch the “Memory Resident
Q. I want to write some assembly language for my C++ project, but I can’t! The C++ compiler doesn't have an inline assembler and I can't figure out how to call my C++ functions from THINK C. Is there no hope?
A. You can call a C++ function from within an inline assembler block in the same way you would a C function: just JSR to the function. There is a slight complication though: the C++ language implements its type-safe linkage by “mangling” the name of functions and methods to contain the type information. So to call a C++ function from C, you need to use its mangled name. You can get the mangled name by turning on the “Generate MacsBug names” option in the Symantec C++ options dialog and disassembling the file containing the function whose mangled name you want. The mangled name will appear in a string at the end of the function. For example, assume that foo.cp contains the function:
Translator” from 1 to 0.
Q. I’ve got the .o extension mapped to the .o Converter. Why doesn’t my .o file appear in the Add Files... list?
A. In addition to having an extension for which there’s a translator, translators will only accept certain file types. A .o file must be of type ‘OBJ ’. If your .o file has “been around” (e.g. you downloaded it from an online service) it may have lost the ‘OBJ ’.
Q. I’m using your “Save Project as Text” and “Create Project From Text” scripts. They work fine except for one small problem: they don’t restore my project’s settings.
A. This is indeed a shortcoming of these scripts. Unfortunately, the data structures which hold the project settings don’t lend themselves easily to the “Save as Text” approach. Here’s a straightforward script to run after running “Create Project from Text” which allows you to copy the project settings from the original project to the new one. Not quite as nice as actually saving the settings as text along with the rest of the project, but it will fill the gap in many situations:
!coddexamplestart
/* 3 */
copy "Hard Drive:Proj Folder:newProj.Π" to targetProjName
tell application "THINK Project Manager"
tell project document 1
copy project type to projType
copy options block 1 to options1
copy options block 2 to options2
copy options block 3 to options3
copy options block 4 to options4
copy options block 5 to options5
close
end tell
open file targetProjName
tell project document 1
set project type to projType
set options block 1 to options1
set options block 2 to options2
set options block 3 to options3
set options block 4 to options4
set options block 5 to options5
end tell
end tell
!coddexampleend
