Xref: utzoo comp.sys.ibm.pc.misc:8603 comp.windows.ms.programmer:1845
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!bu.edu!polygen!jerry
From: jerry@polygen.uucp (Jerry Shekhel)
Newsgroups: comp.sys.ibm.pc.misc,comp.windows.ms.programmer
Subject: Re: Using Borland C++
Message-ID: <1043@stewart.UUCP>
Date: 13 Apr 91 22:31:41 GMT
References: <1991Apr5.171426.28904@SanDiego.NCR.COM> <1038@stewart.UUCP> <1991Apr11.162855.10164@SanDiego.NCR.COM>
Reply-To: jerry@stewart.UUCP (Jerry Shekhel)
Organization: Polygen Corporation, Waltham, MA
Lines: 57

davel@booboo.SanDiego.NCR.COM (David Lord) writes:
>
>3) Run BCX (protected mode compiler).
>
>	This means running Windows in REAL mode. Sounds awful, but I'll
>	try. Actually I thought I had tried this at one point, but I
>	don't remember just what I was doing at the time. Since BC shows:
>	"175k memory remaining" the whole time I'm linking I didn't
>	think swapping was the problem.
>

No.  This means running Windows in Standard (286) Mode.  This mode is just
as good as enhanced, except you don't get V86 DOS windows or virtual memory.
It's even faster than Enhanced mode.

>
>In article <1038@stewart.UUCP> jerry@stewart.UUCP (Jerry Shekhel) writes:
>
>>I have a question about pre-compiled headers.  This feature is a miracle,
>>but it seems like a new header image (.SYM) needs to be created during the MAKE
>>process whenever a file is compiled which includes a set of headers which is
>>different from the current .SYM image.  In other words, the project maintains
>>only one .SYM image.  So if your project contains two files, each including
>>a different set of headers, turning on the pre-compiled header option doesn't
>>save you any time.  Is there a way around this, so that the project can
>>handle multiple .SYM files (disk space is not a problem)?
>
>Use the same headers in each module :-). Actually I think only the first few
>have to be the same.
>

Actually, I do use the same headers in each file, but in order to save myself
from having to keep track of my external variables in two places, I do this:

#ifndef EXTERN
#define EXTERN extern
#endif
[...]
EXTERN HWND MyWindow;
[...]

Then, in MAIN.C I have "#define EXTERN" to force the variables to actually
"materialize" in MAIN.OBJ.  This causes BC to recompile the headers before and
after compiling MAIN.C.  

I have found, however, that I can use some pragma to selectively prevent
header compilation for certain files, and this reduces the number of header
compilation steps necessary for a complete build.
--
+-------------------+----------------------+---------------------------------+
| JERRY J. SHEKHEL  | POLYGEN CORPORATION  | When I was young, I had to walk |
| Drummers do it... | Waltham, MA USA      | to school and back every day -- |
|    ... In rhythm! | (617) 890-2175       | 20 miles, uphill both ways.     |
+-------------------+----------------------+---------------------------------+
|           ...! [ princeton mit-eddie bu sunne ] !polygen!jerry             |
|                            jerry@polygen.com                               |
+----------------------------------------------------------------------------+