home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / lang / cplus / 18784 < prev    next >
Encoding:
Text File  |  1993-01-06  |  2.8 KB  |  82 lines
  1. Newsgroups: comp.lang.c++
  2. Path: sparky!uunet!stanford.edu!lucid.com!lucid.com!jss
  3. From: jss@lucid.com (Jerry Schwarz)
  4. Subject: Re: Standard library functions and macros
  5. Message-ID: <1993Jan7.042121.23809@lucid.com>
  6. Sender: usenet@lucid.com
  7. Reply-To: jss@lucid.com (Jerry Schwarz)
  8. Organization: Lucid, Inc.
  9. References: <1993Jan2.191336.28542@taumet.com> <1993Jan04.231519.8704@microsoft.com> <1993Jan5.032555.12777@lucid.com> <1993Jan06.183334.4535@microsoft.com>
  10. Date: Thu, 7 Jan 93 04:21:21 GMT
  11. Lines: 69
  12.  
  13. I am going to respond to a few of the technical points.  
  14.  
  15.  
  16. jss:
  17. |> |For example, in C++ modes our headers contain (after expansion of
  18. |> |some macros that allow us to control variation between compilation modes)
  19. |> |
  20. |> |    typedef void (*__sigtype)(int);
  21. |> |    typedef void (*__alt_sigtype)(int,int,struct sigcontext*,char*);
  22. |> |
  23. |> |    /* The C standard declaration */
  24. |> |    extern "C" __sigtype signal(int,__sigtype) ;
  25. |> |
  26. |> |    /* A variant expected by Sun programmers */
  27. |> |    extern "C++" inline __alt_sigtype signal(int __sig,  __alt_sigtype __h) {
  28. |> |        return (__alt_sigtype)signal( __sig, (__sigtype)__h) ;
  29. |> |    }
  30. |> 
  31.  
  32. jimad:
  33. |> Seems to me that an inline call such as this requires a stub, either in
  34. |> the library, or compile-time generated, if the programmer does anything
  35. |> that prevents inline expansion of the inline function.
  36.  
  37. If I call the "alt" version
  38.  
  39.     void handler(int,int,sigcontext*, char*) ;
  40.     ...
  41.     signal(0,handler) ;
  42.  
  43. The compiler generates a direct call to the C function. No stub
  44. is layed down.  If I do something that requires a function pointer
  45. [Sorry I'm using the types, but it's too confusing otherwise]
  46.  
  47.     __alt_sigtype (*paltsig)(int, __alt_sigtype)) = signal ;
  48.  
  49. A (static) stub is created.  
  50.  
  51. jimad:    
  52. |>   And such control
  53. |> over inline expansion is precisely the control permitted deliberately
  54. |> and explicitly in the base doc -- the ANSI-C base doc.
  55.  
  56. You keep saying this, but you don't explain how you arrive at that
  57. conclusion.  What the C standard allows is being sure that a
  58. macro isn't in scope.  It does not let you control whether the standard
  59. functions are inlined. 
  60.  
  61. jss:
  62. |> |The extern "C" variant gets linked directly to Sun's C library
  63. |> |without any problems. We don't need stubs.
  64. |> 
  65. jimad:
  66. |> What happens when you take a type-correct pointer to the above function,
  67. |> for example, and invoke via that pointer?  I'd think you'd get a stub
  68. |> generated -- ie the compiler lays down an out-of-line function to implement
  69. |> the alt signal function.
  70. |> 
  71.  
  72. I explicitly refered to the extern "C" variant.  
  73.  
  74.     __sigtype (*psig)(int,__sigtype) = signal ;
  75.     (*psig)(0,(__sigtype)0) ;
  76.  
  77. The value stored in psig is a pointer into the C library,
  78. and a call is made directly to that function in the second line.
  79. Most of the standard library functions would not have variants.
  80.  
  81.   -- Jerry Schwarz
  82.