Think Top 10

By Scott Shurr, THINK Technical Support, Symantec Corp.

Q. How closely does Symantec C++ conform to the language described in The Annotated C++ Reference Manual (ARM) by Margaret A. Ellis and Bjarne Stroustrup?

A. Symantec C++ is AT&T CFront 3.0 compliant, and conforms to the ARM in all respects except for exception handling, which has not yet been implemented.

Q. Will libraries built with THINK C 5.0 work under Symantec C++?

A. The libraries themselves will, for the most part, work as expected. There are a couple of points to keep in mind though. The C++ compiler uses 4-byte integers and native floating point format, so if your library uses variables declared int (which are 2-bytes in THINK C but 4-bytes in Symantec C++) or floating point (float, double, long double, extended) then you should rebuild it with THINK C 6.0 using these settings or port it to C++. The other thing to keep in mind is that C and C++ use different calling conventions, so you will need to modify your header files to contain a C linkage specification for the prototypes. A typical sequence is:

 #if __cplusplus
 extern "C" {
 #endif
 //  
 // Your prototypes go here
 //  
 #if __cplusplus
 }
 #endif

Take a look at one of the standard library header files if you want to see this mechanism in action.

Q. How do you convert THINK Class Library projects from 5.x to 6.0? To C++?

A. The safest way to do the conversion is to start with the 6.0 Starter application: the TCL 1.1.3 sources all have the file extension .cp (with the exception of a handfull with .asm), so you can’t just bring your existing 5.0 TCL project over and expect it to build. By using the Starter app you get the right extension mappings and options at no cost (other than adding and segmenting your sources). For a THINK C based TCL project, you should have .c, .asm, and .cp all mapped to the THINK C translator. If you want to build your existing TCL application using C++, then you can add the files to the C++ based Starter app, and change the extension mapping for .c from THINK C to Symantec C++. This is very imporatant: the object model used in the THINK C object extensions are not compatible with C++, and you will get many link errors if you forget to change the mapping.

Q. The THINK C User’s Guide says that if I option double-click on the name of a Toolbox or standard library function, then THINK reference will open up and show me the documentation for that function. But it isn’t working all the time, why?

A. If THINK Reference isn’t running on your machine, then option double-clicking will not launch it: you need to chose "Find in THINK Reference" from the Search menu, or press -minus ('-'). Once you have launched it then you will be able to use option double-click to perform lookups.

Q. What is "Internal Error ZREF," and what can I do about it?

A. It means that your project file is corrupted. Removing objects from the project and rebuilding may fix it, providing the corruption was in the object portion of the project. If it wasn’t, you need to create a new project and add the sources into it. If your project file grows towards 16 megabytes, you may also see this error. Try storing your debug info separately: this will cut down on the project size. Unfortunately this still means you will need to rebuild the project from scratch. If you have AppleScript then you can use the "Save project as text" and "Create project as text" AppleScripts (in the ':Scripting:Sample AppleScripts' folder) to automate this task.

Q. When compiling a C++ source file, a syntax error in my .h file is reported in the errors window. When I double-click to open the .h file, I don’t see anything that looks wrong, so I do Check Syntax. Now I don’t get any errors. But when I go back to the original file and try compiling again, I get the same error.

A. You can’t do Check Syntax on files that do not have a translator mapping, and .h files are not part of the default set of mappings. If you set the THINK Project Manager’s extension mapping to map .h to THINK C or Symantec C++, you will be able to directly check such a file, and see the errors. (Note that compiling this a .h file will add it to the project!) Another solution, which doesn’t require changing the extension mappings, is to preprocess the file, saving the resulting file with a .c or .cp extension (which is appropriate) and compiling it.

Q. Can I include my "projectname.rsrc" file in my project?

A. You can, but you may cause a “duplicate resource” error. The default extension mapping for .rsrc files specifies that the Resource Copier as the translator. Since the Resource Copier copies its input into the “projectname.rsrc” file (creating it if necessary), you will get that error. You can prevent this from happening by naming the file something other than “projectname.rsrc”. If you have multiple .rsrc files in the project, the contents of each will be copied into “projectname.rsrc”. You could also set the .rsrc translator to «none», but that would defeat the advantages of having the project automatically keep track of the resources.

Q. I’m building a TCL project in THINK C 6.0 that I know will need far code and far data, so I take the starter project, replace oopsDebug with oopsDebugFar, set Far Data and Far Code, and select Bring Up To Date. I get the following compile error:

File <LongQD.cp>; Line 28
Error:     second argument to function ‘__member’ does not match prototype

A. The member() function is declared in oops.h, which gets included in the precompiled header, TCLHeaders. Its second argument gets declared as a void * if either far code or far data are on, but as a short if not. Hence the prototype mismatch. The manual, by mentioning that you must include oops.h in all far TCL projects, is subtly whispering that perhaps you should recompile TCLHeaders with far options on.

Q. I’m trying to use the lowercase, C style newcdialog() function, which is declared in Dialogs.h - but the linker tells me it’s undefined. I have MacTraps and MacTraps2 in my project. What’s the problem?

A. The declarations for these functions are in there because we use the headers supplied by Apple. However, these functions are implemented via glue that only works in MPW. We have never, and probably will never, support them.

Q. I have a strange problem with THINK C. It beeps at the end of compilation, without displaying any message or alert. The beep occurs only when I compile all files of the project together, not when I compile a single file. This is very disturbing. What can I do to recover normal behavior?

A. It’s a feature! If you’re compiling a lot of files, the beep occurs so you will know to end your coffee break and get back to work.