home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / lang / cplus / 16625 < prev    next >
Encoding:
Text File  |  1992-11-20  |  3.9 KB  |  92 lines
  1. Newsgroups: comp.lang.c++
  2. Path: sparky!uunet!cs.utexas.edu!uwm.edu!linac!att!cbnewsk!cbnewsj!att-out!cbfsb!cbnewsg.cb.att.com!nh
  3. From: nh@cbnewsg.cb.att.com (nicholas.hounsome)
  4. Subject: Re: Idempotent header file proposal
  5. Message-ID: <1992Nov20.103616.19956@cbfsb.cb.att.com>
  6. Sender: news@cbfsb.cb.att.com
  7. Organization: AT&T
  8. References: <1992Nov20.010009.24900@taumet.com>
  9. Date: Fri, 20 Nov 1992 10:36:16 GMT
  10. Lines: 80
  11.  
  12. From article <1992Nov20.010009.24900@taumet.com>, by steve@taumet.com (Steve Clamage):
  13. > nh@cbnewsg.cb.att.com (nicholas.hounsome) writes:
  14. > 
  15. >>Can we not have a standard pragma to say that a header file is idempotent
  16. >>(A long word  I discovered that means that it only need be included once).
  17. > 
  18. > Not quite.  It means that (in this context) multiple inclusions have
  19. > the same effect as one inclusion.
  20. > 
  21.  
  22. I think that what I said means the same thing
  23.  
  24. >>eg. put #pragma IDEMPOTENT in the header and have the preprocessor
  25. >>understand that it need not bother reading this file again it seems
  26. >>very easy to implement provided only that you use an ANSI preprocessor
  27. >>and it requires no language extension since it is only a convention
  28. >>which the preprocessor can ignore if it does not understand it.
  29. > 
  30. > Some compilers have this feature, often called "#pragma once".
  31. > 
  32. > This solves a problem outside the language, and for that reason is
  33. > probably not appropriate to put in the language Standard.  In
  34. > particular, you are assuming that a standard header is a file, and
  35. > that it is read and processed by the compiler in the way user text
  36. > files are processed.  Nothing in the language specification requires
  37. > this to be the case.  Any compiler is free to recognize the names of
  38. > the standard headers and do any kind of magic, so long as the net
  39. > result is what the Standard specifies.
  40.  
  41. The "standard" headers are not too much of a problem it is 
  42. headers from large libraries such as GUIs and user headers that
  43. make up the bulk.
  44.  
  45. > 
  46. > For example, the compiler could have the contents of the standard
  47. > headers already available in its symbol table but inactive when
  48. > the compiler starts up.  It would activate the definitions
  49. > associated with a standard header when the include directive was seen.
  50. > This takes no time, and has no penalty if done more than once.
  51. > 
  52. > One problem with pragmas is that they are not necessarily harmless
  53. > when not implemented on another compiler.  My favorite example, for
  54. > which I cannot take credit, involves "#pragma once".  As I noted
  55. > earlier, on some compilers it means "ignore further requests to
  56. > include this header."  On another compiler, it might mean "turn
  57. > on Customer Engineer features."  These features are turned off
  58. > with "#pragma offce".
  59. > 
  60. > Many people involved with standards efforts believe that there should
  61. > not be such a thing as a "standard pragma".  A pragma by its nature
  62. > controls something non-standard, non-portable, or system-specific.
  63. > If the thing controlled were generally portable, it should probably
  64. > be a language feature, not a pragma.
  65. > -- 
  66.  
  67. Point taken.
  68.  
  69. The reason that I suggested a pragma was to minimize impact on existing code.
  70.  
  71. I could have suggested changing the semantics of #include but I know that
  72. this would break the 0.0001% of code that intentionaly includes headers
  73. multiple times.
  74.  
  75. How about a different form for #include such as say #use with the
  76. corresponding meaning?
  77.  
  78. > Steve Clamage, TauMetric Corp, steve@taumet.com
  79. > Vice Chair, ANSI C++ Committee, X3J16
  80.  
  81. Others have pointed out that some compilers notice when header code is
  82. wrapped in #ifdef HEADER1_H but this seems messy to me and I consider
  83. readability to be a major issue.
  84.  
  85. Also for those people who say that nothing should be done because it isn't a 
  86. language problem or can be worked around I would point out that this
  87. applies equaly to everything that the preprocessor does. The object is
  88. to get maintainable programs produced as fast as possible.
  89.  
  90. Nick Hounsome
  91. AT&T Network Systems UK
  92.