home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / lang / cplus / 18165 < prev    next >
Encoding:
Text File  |  1992-12-20  |  2.6 KB  |  72 lines
  1. Newsgroups: comp.lang.c++
  2. Path: sparky!uunet!uunet.ca!frumious!pat
  3. From: pat@frumious.uucp (Patrick Smith)
  4. Subject: Standard library functions and macros
  5. Message-ID: <BzFM01.CD@frumious.uucp>
  6. Date: Fri, 18 Dec 1992 01:40:48 GMT
  7. Reply-To: uunet.ca!frumious!pat
  8. References: <1992Dec07.195917.14566@microsoft.com> <BzCFyM.2r5@frumious.uucp> <1992Dec16.185914.664@microsoft.com>
  9. Organization: None
  10. Lines: 60
  11.  
  12. jimad@microsoft.com (Jim Adcock) writes:
  13. |Verses it would be nice to be able to port C code to C++ without having
  14. |to rewrite the whole da*ned thing.  My concern is that I am seeing people
  15. |*trying* to port C to C++ and having a hellish time of it.
  16.  
  17. Hmmm.  My one experience at porting C code (about 80,000 lines of it,
  18. if I remember correctly) to C++ went quite smoothly.  Different cases,
  19. different experiences.
  20.  
  21.  
  22. Suppose the C++ standard said that standard library functions must
  23. have external linkage, and prohibited implementing them as macros.
  24. Would this change the meaning of any C programs if compiled as C++?
  25.  
  26. Under this rule, it would still be possible (even easy) for compilers
  27. to substitute inline code for most calls to certain library
  28. functions.  For example, <strings.h> might contain
  29.  
  30.    size_t strlen(const char* p);
  31.  
  32.    inline size_t __strlen(const char* p) {
  33.       size_t n = 0;
  34.       while (*p++) n++;
  35.       return n;
  36.    }
  37.  
  38. The only extra knowledge this would require in the compiler is some
  39. way to know that calls to strlen could be replaced by calls to
  40. __strlen.
  41.  
  42. (This is just meant as an easy way for compilers to inline calls.
  43. In practice, I suspect many compiler writes might embed the
  44. knowledge of how to generate inline code for some functions
  45. directly in the compiler, without using tricks such as the above.)
  46.  
  47.  
  48. |I'm seeing though.  Further, the proposed
  49. |changes take away the ability to selectively decide whether a std library
  50. |should be implemented in one's code via a function call, or an inline
  51. |[albeit macro] expansion, without giving programmers an equivalent functionality
  52.  
  53. Do they?
  54.  
  55. As Steve Clamage pointed out, you can call the function through a
  56. function pointer; this will probably cause the compiler to
  57. generate a true function call.
  58.  
  59. Going the other way, if the _implementation_ is prohibited from
  60. making putchar a macro, the _programmer_ should be permitted to
  61. make putchar a macro.  So the programmer who wants to force
  62. inline code for putchar can simply write the macro.  A particular
  63. implementation might choose to make this easier by providing
  64. a __putchar macro so the programmer could write
  65.  
  66.    #define putchar(c) __putchar(c)
  67.  
  68. -- 
  69. Patrick Smith
  70. uunet.ca!frumious!pat
  71. pat%frumious.uucp@uunet.ca
  72.