home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / lang / cplus / 16783 < prev    next >
Encoding:
Text File  |  1992-11-23  |  2.4 KB  |  50 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: <1992Nov23.154049.81707@Cookie.secapl.com>
  6. Date: Mon, 23 Nov 1992 15:40:49 GMT
  7. References: <1992Nov20.010009.24900@taumet.com> <1992Nov21.175456.119915@Cookie.secapl.com> <1992Nov22.173734.2042@taumet.com>
  8. Organization: Security APL, Inc.
  9. Lines: 39
  10.  
  11. In article <1992Nov22.173734.2042@taumet.com> steve@taumet.com (Steve Clamage) writes:
  12. >frank@Cookie.secapl.com (Frank Adams) writes:
  13. >>In article <1992Nov20.010009.24900@taumet.com> steve@taumet.com (Steve Clamage) writes:
  14. >>>nh@cbnewsg.cb.att.com (nicholas.hounsome) writes:
  15. >>>>Can we not have a standard pragma to say that a header file is idempotent
  16. >>>
  17. >>>This solves a problem outside the language, and for that reason is
  18. >>>probably not appropriate to put in the language Standard. [...]
  19. >
  20. >>This is a generic problem; it
  21. >>does *not* apply only to some systems.  So a standard is appropriate; but if
  22. >>it is neither to be a language standard nor a standard pragma, how is it to
  23. >>be done?
  24. >
  25. >Some compilers are very slow.  How about a standard pragma "#pragma fast"
  26. >which would direct the compiler to compile more quickly if it could.
  27. >Some compilers require too much memory at compile time.  How about a
  28. >standard pragma "#pragma small" which would direct the compiler to use
  29. >less memory if it could.  If the compiler could not comply, it would
  30. >ignore these pragmas.
  31. >
  32. >I hope these suggestions sound silly to you.  These, along with the
  33. >repeated include file problem, are not C++ (or C) language problems.
  34. >They are "quality of implemenation" issues.
  35.  
  36. I can't agree.  Whether I want an include file inserted only the first time
  37. it is seen, or every time, is part of the specification of the program.
  38. Inserting #if !defined ... #endif around the body of the file is already a
  39. kludge.  One can make a compiler which deals with this kludge better; this
  40. is indeed a quality of implementation issue.
  41.  
  42. But it is not a quality of implementation issue to ask for the feature I and
  43. a lot of other people really want, instead of a kludge to get around its
  44. absence.
  45.  
  46. Based on this, it would seem that a pragma is the wrong way to go.  I would
  47. suggest #once.  (#idempotent suggests that including the file more than once
  48. is the same as including it once.  But if we take out the #if[ndef] hack,
  49. this is no longer the case.)
  50.