home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / lang / cplus / 16789 < prev    next >
Encoding:
Text File  |  1992-11-23  |  2.0 KB  |  43 lines

  1. Newsgroups: comp.lang.c++
  2. From: nikki@trmphrst.demon.co.uk (Nikki Locke)
  3. Path: sparky!uunet!pipex!demon!trmphrst.demon.co.uk!nikki
  4. Subject: Re: Idempotent header file proposal
  5. Reply-To: nikki@trmphrst.demon.co.uk
  6. Distribution: world
  7. X-Mailer: cppnews $Revision: 1.20 $
  8. Organization: Trumphurst Ltd.
  9. Lines: 29
  10. Date: Mon, 23 Nov 1992 12:36:19 +0000
  11. Message-ID: <722547379snx@trmphrst.demon.co.uk>
  12. Sender: usenet@gate.demon.co.uk
  13.  
  14. In article <1992Nov20.200435.18239@microsoft.com> jimad@microsoft.com (Jim Adcock) writes:
  15. > Ultimately we will begin to see more and more C++
  16. > development environments that not only offer precompiled headers, but
  17. > incremental compile/link support as well.
  18. It is unfortunate that most of the current compilers which have
  19. precompiled headers have such restrictions on their use, and such arcane 
  20. command lines to use them, that they introduce problems, rather than 
  21. solving them.
  22.  
  23. For example, all the compilers I have seen with this feature insist that 
  24. all modules that use the precompiled headers include the same headers, in 
  25. exactly the same order. This encourages users to include ALL their headers
  26. in all their modules. This introduces lots of unnecessary dependencies, 
  27. and means a very slow compile cycle when the code is moved to another 
  28. compiler, without precompiled headers.
  29.  
  30. Unfortunately, this awfulness is likely to spread - in the first place, 
  31. compiler vendors who have precompiled headers see this method as a good 
  32. thing, because it locks users into their compiler. Compiler vendors 
  33. introducing precompiled headers feel they should implement them in a 
  34. way compatible with (e.g.) Microsoft.
  35.  
  36. Of course, having "proper" separately precompiled headers, which can be 
  37. individually included only when actually needed, is much more difficult to
  38. do, so we are probably stuck with the (IMHO) nasty hack vendors supply at 
  39. present.
  40. -- 
  41. Nikki Locke,Trumphurst Ltd.(PC and Unix consultancy) nikki@trmphrst.demon.co.uk
  42. trmphrst.demon.co.uk is NOT affiliated with ANY other sites at demon.co.uk.
  43.