home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / lang / cplus / 18612 < prev    next >
Encoding:
Text File  |  1992-12-31  |  4.2 KB  |  75 lines
  1. Newsgroups: comp.lang.c++
  2. Path: sparky!uunet!microsoft!hexnut!jimad
  3. From: jimad@microsoft.com (Jim Adcock)
  4. Subject: Re: Standard library functions and macros
  5. Message-ID: <1992Dec31.190217.11860@microsoft.com>
  6. Date: 31 Dec 92 19:02:17 GMT
  7. Organization: Microsoft Corporation
  8. References: <921231032705_76336.3114_EHJ60-1@CompuServe.COM>
  9. Lines: 64
  10.  
  11. In article <921231032705_76336.3114_EHJ60-1@CompuServe.COM> 76336.3114@CompuServe.COM (Kevin Dean) writes:
  12. |Why should function names be reserved?  They are functions, after all, and
  13. |are thus outside the definition of the language.  
  14.  
  15. "Reserved" in the same sense that ANSI-C reserved them -- that is if you
  16. #include the corresponding ANSI-C standard header, then the function
  17. names in that standard header become reserved.  If this is not acceptible,
  18. then simply don't include that standard header file.  Standard functions
  19. are indeed part of the definition of the language.  Any compiler that
  20. does not implement the required standard libraries and functions and 
  21. cannot be said to be a conforming implementation of the language.
  22.  
  23. ANSI-C standard function names should continue to be reserved under the
  24. same conditions as ANSI-C because ANSI-C represented a three-way contract
  25. between standardizers, implementors, and programmers.  Implementations and
  26. programmers using those implementations have written code under the assumption
  27. that these agreements would be maintained, not broken.  ANSI-C is a base
  28. document to the ANSI-C++ effort, and thus should only be changed when
  29. in conflict with ARM, which is the overriding base document.  Standardization
  30. efforts such as ANSI-C and ANSI-C++ are suppose to standardize on common
  31. practice, not implement new practice out of whole cloth.  In the case of
  32. the ANSI-C standard libraries, ANSI-C is clearly the standard practice.
  33. Again, neither the C++ programmer nor the standardizers need to use the
  34. ANSI-C headers nor standard functions if they do not agree to that
  35. existing standard practice.  The C++ standardizers could invent the own,
  36. differently named header files, for example, if they insist on inventing
  37. new standard practice.
  38.  
  39. |If they have to be
  40. |overridden or defined as macros, can't they just be inlined?  Off the top
  41. |of my head, I can only think of the assert() macro that couldn't be
  42. |rewritten as an inline function because it has to dump context-sensitive
  43. |information like file and line number if it's to be of any use.
  44.  
  45. A simple additional example is 3rd party debugging mallocs.  If the
  46. standardization committee insists on inline implementations, not macros,
  47. such 3rd party libraries would suddenly no longer be supportable.
  48. Again, my claim is that there is a lot of work that has been done under
  49. the "legal" guidelines of ANSI-C that would be broken by now requiring
  50. new additional constraints prohibiting macro implementations.
  51.  
  52. |The reason I say this is that reserving the function names can make for
  53. |severe maintenance headaches.  Suppose I have a class that has member
  54. |functions read() and write() and the C-standard read() and write() have
  55. |been redefined as macros by the compiler.  What then?  
  56.  
  57. The compiler does not redefine read() and write() as macros.  You do --
  58. by #including the corresponding ANSI-C headers.  If you do not accept
  59. the rules laid down by ANSI-C, you can simply choose not to #include the
  60. ANSI-C header that laid down those rules.  You can still get to
  61. the function implementations of read() and write() simply by declaring
  62. such without #including the ANSI-C headers.  ANSI-C guarantees that
  63. implementations provide the function implementations in addition to the
  64. macro implementations if the macros are defined at all.
  65.  
  66. If the ANSI-C++ standardization committee wanted to include differently-named
  67. headers in addition to the ANSI-C headers, and the new ANSI-C++ headers follow
  68. rules specific to C++, then I'd see no problem.  Existing code and conventions
  69. would continue to compile and execute correctly, macro implementations of
  70. assert and malloc or whatever could continue to do their thing, and
  71. people writing new code could simply choose to use the C++ headers.
  72. The ANSI-C++ standard could even declare the C headers obsolecent, so
  73. that the next version of the C language [god help us all ;-] wouldn't 
  74. have to support the ANSI-C rules at all.
  75.