home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / lang / cplus / 19037 < prev    next >
Encoding:
Text File  |  1993-01-12  |  2.3 KB  |  45 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: <1993Jan12.191639.8524@microsoft.com>
  6. Date: 12 Jan 93 19:16:39 GMT
  7. Organization: Microsoft Corporation
  8. References: <1993Jan5.032555.12777@lucid.com> <1993Jan06.183334.4535@microsoft.com> <1993Jan7.042121.23809@lucid.com>
  9. Lines: 34
  10.  
  11. In article <1993Jan7.042121.23809@lucid.com> jss@lucid.com (Jerry Schwarz) writes:
  12. |jimad:    
  13. ||>   And such control
  14. ||> over inline expansion is precisely the control permitted deliberately
  15. ||> and explicitly in the base doc -- the ANSI-C base doc.
  16. |
  17. |You keep saying this, but you don't explain how you arrive at that
  18. |conclusion.  What the C standard allows is being sure that a
  19. |macro isn't in scope.  It does not let you control whether the standard
  20. |functions are inlined. 
  21.  
  22. You are looking at it from the strictly conforming programmers point of
  23. view.  I am discussing it from the implementors and the conforming
  24. programmers point of view.  You right that ANSI-C doesn't require either
  25. a non-inline or an inline implementation.  ANSI-C does require that if
  26. an inline [macro] implementation is given that a non-inline implementation
  27. also be present.  It is true that an optimizing compiler or linker could
  28. take the non-inline and make it inline again.  This is the as-if rule.
  29. So there is no strictly-conforming way the programmer can be guaranteed
  30. this control.
  31.  
  32. However, from the view of the implementer and the conforming programmer,
  33. implementations can and do follow the ANSI-C guidelines for how the
  34. standard libraries are "suppose" to work.  And *conforming* programs
  35. and programmers do make use of the features of those conforming implementations.
  36. You are now suggesting removing the [reasonable] possibility of 
  37. implementations continuing to support the ANSI-C libraries in the
  38. manner the ANSI-C document calls out.  You have destroyed a clear intent
  39. of the ANSI-C document, and you have done so without allowing for the
  40. obsolecense period called for in the ANSI-C document.  This is a clear
  41. violation of the ANSI-C base document.  Again, if you insist on violating
  42. the rules laid down by the ANSI-C base document, then the ANSI-C++
  43. committee should not claim the ANSI-C document is one of their
  44. base documents.
  45.