home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / lang / cplus / 16728 < prev    next >
Encoding:
Text File  |  1992-11-22  |  2.8 KB  |  61 lines
  1. Newsgroups: comp.lang.c++
  2. Path: sparky!uunet!taumet!steve
  3. From: steve@taumet.com (Steve Clamage)
  4. Subject: Re: Idempotent header file proposal
  5. Message-ID: <1992Nov22.173734.2042@taumet.com>
  6. Organization: TauMetric Corporation
  7. References: <1992Nov19.090742.23696@cbfsb.cb.att.com> <1992Nov20.010009.24900@taumet.com> <1992Nov21.175456.119915@Cookie.secapl.com>
  8. Date: Sun, 22 Nov 1992 17:37:34 GMT
  9. Lines: 50
  10.  
  11. frank@Cookie.secapl.com (Frank Adams) writes:
  12.  
  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. Please note I am not saying that an implementation should not provide
  37. pragmas (or command-line flags) to cater to specific features of the compiler
  38. or runtime system (including "fast", "small", or "once" pragmas).  I am
  39. saying that these are not issues for the language specification to address.
  40.  
  41. [Perhaps we have a slight communication problem.  When I use the word
  42. "standard", I mean in the sense of an agreed-upon language specification.
  43. For C, this means the ANSI/ISO C Standard.  For C++, it currently means
  44. the ARM, and will eventually mean the ANSI/ISO C++ Standard.  I don't
  45. use the word "standard" to mean merely "popular".]
  46.  
  47. As Jim Adcock has noted in another posting, compilers exist which address
  48. the include file problem without requiring source code modification.
  49. Precompiled headers and incremental compilation are two ways existing
  50. compilers avoid entirely the problem you are trying to fix with a language
  51. extension.  Other solutions are also possible.
  52.  
  53. If your compiler is too slow or uses too much memory, get another one
  54. which better suits your needs, or lobby your vendor to make improvements.
  55. If your compiler doesn't deal intelligently with repeated includes,
  56. take similar measures.
  57. -- 
  58.  
  59. Steve Clamage, TauMetric Corp, steve@taumet.com
  60. Vice Chair, ANSI C++ Committee, X3J16
  61.