Sep 93 Think 10
Volume Number: | | 9
|
Issue Number: | | 9
|
Column Tag: | | Think Top 10
|
Think Top 10
By Thomas Emerson, THINK Technical Support, Symantec Corp.
This a monthly column written by Symantec's Technical Support Engineers intended to provide you with information on Symantec products. This month we cover some more commonly asked questions of Symantecs developer technical support group.
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:
void foo()
{
for(int i=0;i<10;i++)
;
}
Disassembling foo.cp yields in part the following:
00000012: 261F MOVE.L (A7)+,D3
00000014: 4E75 RTS
00000016: 8766 6F6F 5F5F DC.B $80+$07, 'foo__Fv'
4676
0000001E: 0000 DC.W 0 ; size of literals
00000020
The mangled name for foo() is foo__Fv. So to call it from within the inline assembler we would write:
asm {
jsr foo__Fv
addq.l #4,sp
};
remembering to prototype the function correctly, i.e.
extern void foo__Fv(void);
and remember to use C++ calling conventions when passing arguments to the function. See pp. 73-75 of the C++ Compiler Guide for more details.
Q. On a related note, whenever I try to use the asm() statement in C++, I'm told that the function asm has no prototype. What's going on?
A. You will get this error if you have ANSI conformance option turned on in the Language Settings page of the Symantec C++ for Macintosh options dialog. As it says on page 40 of the C++ Compiler Guide , the keyword asm is not recognized. Turn this off and you will be all set.
Q. Can I build a code resource using Symantec C++ that uses C++ objects?
A. Sure, you can use C++ objects in code resources, though they cannot contain virtual methods. This is because the resource loader code does not support the 32-bit offsets used to build the vtables that are used for virtual method dispatch. We would recommend deriving all of your classes from PascalObject, which will support virtual methods and is an all around better way of doing it.
Q. It appears that your IOStreams library doesn't work when I turn on 68881 code generation. I built a version of IOStreams with the C++ compiler set to generate 881 instructions, but the simplest programs still don't work. What's wrong?
A. There are two things you need to do when using IOStreams with 68881 code generation. The library itself contains both C and C++ code, so you need to turn on 881 code generation for both the THINK C and Symantec C++ compilers. You also need to build a version of ANSI++ that uses 68881 code generation, since IOStreams makes calls to ANSI++ to do the dirty work.
Q. Im a little confused on the difference between Stream.h and iostream.h. When should I use one and not the other?
A. The short and sweet answer is that you should ignore Stream.h completely and always use iostream.h. Stream.h contains the classes for the old Streams library described in the first edition of The C++ Programming Language. The header file is part of the Symantec C++ for Macintosh distribution, but the library itself was left out (though it is part of the MPW version, called SCOldstreamsIO.o and SCOldstreamsIO881.o). Unless you are porting old C++ source code that uses Stream.h you should use iostream.h instead.
Q. Since we're talking about streams here, I've found that when I create an fstream it shows up on my disk as a blank icon, and I can't open it. Is there any way to tell the compiler that I want a THINK C text file?
A. You can use a feature of the standard library to set the type and creator used when creating files. This works because the IOStreams library calls upon ANSI++ to do its dirty work, like creating and opening files. The file <stdio.h> declared two external globals, _ftype and _fcreator. These are used to set the initial type and creator for a file, so settings these to 'TEXT' and 'KAHL' respectively will solve your problem. The following code snippet should give you an idea of what to do:
#include <fstream.h>
#include <stdio.h>
void main()
{
fstream fs;
// set the type and creator for any streams we open
_ftype = 'TEXT';
_fcreator = 'KAHL';
fs.open("foo.bar");
}
Q. I've heard about something called ToolServer. What is it and how do I use it?
A. ToolServer is a product developed by Apple that allows you to execute most MPW tools and scripts (the major exceptions being the editor and Projector commands.) Applications communicate with ToolServer by exchanging Apple events: in effect an MPW command line is sent to ToolServer, and the results of the command sent back to the calling application. The THINK Project Manager provides ToolServer support with this mechanism: if you press Command-Enter within any THINK editing window then the current selection (or the line the cursor is on if there isn't a selection) is sent to ToolServer. The TPM looks for an alias called ToolServer in the Tools folder, and launches this application if ToolServer isn't running.
ToolServer is distributed by Apple on the E.T.O. series (it first appeared in released form on E.T.O. #11) and in the MPW 3.3 distribution, both of which are available through APDA.
Q. Supposedly this is the THINK Top 10, yet there are only 8 questions, counting this one. What's the deal?
A. Well, perhaps we should have called this month's column the THINK Top 010. [read it in octal for those of you scratching your heads. - Ed.]
Thanks to Chris Prinos, Kevin Irlen, and Phil Shapiro for their contributions to the answers this month.