home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / lang / cplus / 16711 < prev    next >
Encoding:
Text File  |  1992-11-21  |  1.7 KB  |  38 lines
  1. Newsgroups: comp.lang.c++
  2. Path: sparky!uunet!secapl!Cookie!frank
  3. From: frank@Cookie.secapl.com (Frank Adams)
  4. Subject: Re: Idempotent header file proposal
  5. Message-ID: <1992Nov21.175456.119915@Cookie.secapl.com>
  6. Date: Sat, 21 Nov 1992 17:54:56 GMT
  7. References: <1992Nov19.090742.23696@cbfsb.cb.att.com> <1992Nov20.010009.24900@taumet.com>
  8. Organization: Security APL, Inc.
  9. Lines: 27
  10.  
  11. In article <1992Nov20.010009.24900@taumet.com> steve@taumet.com (Steve Clamage) writes:
  12. >nh@cbnewsg.cb.att.com (nicholas.hounsome) writes:
  13. >>Can we not have a standard pragma to say that a header file is idempotent
  14. >
  15. >This solves a problem outside the language, and for that reason is
  16. >probably not appropriate to put in the language Standard. [...]
  17. >
  18. >Many people involved with standards efforts believe that there should
  19. >not be such a thing as a "standard pragma".  A pragma by its nature
  20. >controls something non-standard, non-portable, or system-specific.
  21. >If the thing controlled were generally portable, it should probably
  22. >be a language feature, not a pragma.
  23.  
  24. You appear to be contradicting yourself here.  This is a generic problem; it
  25. does *not* apply only to some systems.  So a standard is appropriate; but if
  26. it is neither to be a language standard nor a standard pragma, how is it to
  27. be done?
  28.  
  29. >  In
  30. >particular, you are assuming that a standard header is a file, and
  31. >that it is read and processed by the compiler in the way user text
  32. >files are processed.
  33.  
  34. No, the proposal is for a pragma to be placed in the include file.  As such,
  35. it is directly applicable only to user-defined headers, which must indeed be
  36. files.  Of course, this would in no way prevent compiler-writers from using
  37. it for standard headers, if it was appropriate.
  38.