Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!mips!pacbell.com!ucsd!mvb.saic.com!ncr-sd!SanDiego.NCR.COM!tortuga!jim From: jim@tortuga.SanDiego.NCR.COM (Jim (James) Ruehlin) Newsgroups: comp.lang.c++ Subject: Re: Borland C++ binary header files Message-ID: <1991Jun6.224738.28002@donner.SanDiego.NCR.COM> Date: 6 Jun 91 22:47:38 GMT References: <1991Jun5.220703.662@helios.physics.utoronto.ca> Sender: news@donner.SanDiego.NCR.COM (News Owner) Reply-To: jim@tortuga.SanDiego.NCR.COM (Jim (James) Ruehlin) Organization: NCR Corporation, Rancho Bernardo Lines: 27 In article <1991Jun5.220703.662@helios.physics.utoronto.ca> lamouche@aurora.physics.utoronto.ca (Guy Lamouche) writes: > > I would like some comments on the Borland C++ feature of > having header files in a binary format. Does it speed the > compilation a lot. I want to get Borland C++ and i own a > 5Mhz 512K (don t laugh!) PC. I use the compiled header files extensively. After I realized how they work, it's decreased overall compilation time tremendously. At first, I had compiled headers on but didn't do anything special in my source code to accomodate them. This results in a compiled file being created for each set of #include files in your .c module. This is great if you don't change .h files much, as the only thing that takes time to compile is the lines in your .c file (with no multiple file openings to get at the .h files). However, if you do change .h files more than infrequently you can set up a list of #includes that's in all your .c files. They have to be in the same order and at the very beginning of the .c module. You should terminate the list with a "#pragma hdrstop". I do this with my 8 largest and most common header files and it makes a big difference. As far as your configuration goes, I'm not sure BC++ will run in that much memory. I suppose it could swap to your disk a lot. On the other hand, I use it for Windows programming so I eat up a lot of memory. Good luck! - Jim Ruehlin