home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / lang / cplus / 12528 < prev    next >
Encoding:
Internet Message Format  |  1992-08-18  |  1.5 KB
  1. Path: sparky!uunet!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!rpi!psinntp!psinntp!searchtech.com!mra
  2. From: mra@searchtech.com (Michael Almond)
  3. Newsgroups: comp.lang.c++
  4. Subject: Re: Precompiled headers in Turbo C++ 3.0
  5. Message-ID: <1992Aug18.153123.26357@searchtech.com>
  6. Date: 18 Aug 92 15:31:23 GMT
  7. References: <1992Aug15.045015.42365@kuhub.cc.ukans.edu>
  8. Organization: Search Technology, Inc.
  9. Lines: 23
  10.  
  11. In article <1992Aug15.045015.42365@kuhub.cc.ukans.edu> jeff@kuhub.cc.ukans.edu (Jeff Bangert) writes:
  12. >What I know so far: include files must be in DECREASING order of size.
  13.  
  14. Hmm, I have not found this to be of any importance.
  15.  
  16. >But, when I build a library, with my own .h file, and my own .h file
  17. >includes some .h files, then precompiled headers may or may not work.
  18.  
  19. They should, my do.  On thing I do is create a standard header file for 
  20. each type of source file (file maintenance, records, file I/O, reports, etc).
  21. Then include on this on file at the top of a module followed by #pragma 
  22. hdrstop.  After the #pragma I include all the special *.h for the module.
  23.  
  24. >Since precompiled headers speed up compiles quite a bit, I really like
  25. >them, and it's frustrating when they don't work.
  26.  
  27. Yes they do speed things up, however they work best when you have the
  28. same set of headers marked for pre-compile across several modules.
  29. -- 
  30. Michael R. Almond (Georgia Tech Alumnus)          mra@srchtec.uucp (registered)
  31. computer alli, inc.                        mra@searchtech.com
  32. 6000E dawson blvd.                              uupsi!srchtec!mra
  33. norcross, georgia 30093                        (404) 840-1002 (office)
  34.