home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / lang / cplus / 18639 < prev    next >
Encoding:
Text File  |  1993-01-02  |  3.3 KB  |  71 lines
  1. Newsgroups: comp.lang.c++
  2. Path: sparky!uunet!taumet!steve
  3. From: steve@taumet.com (Steve Clamage)
  4. Subject: Re: Standard library functions and macros
  5. Message-ID: <1993Jan2.191336.28542@taumet.com>
  6. Organization: TauMetric Corporation
  7. References: <BzFM01.CD@frumious.uucp> <1992Dec23.214139.24948@microsoft.com> <1992Dec25.014646.9364@lucid.com> <1992Dec29.213548.5661@microsoft.com> <9300302.725@mulga.cs.mu.OZ.AU>
  8. Date: Sat, 2 Jan 1993 19:13:36 GMT
  9. Lines: 60
  10.  
  11. fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON) writes:
  12.  
  13. >jimad@microsoft.com (Jim Adcock) writes:
  14.  
  15. >>The fact that macro implementations are allowed under ANSI reserves the
  16. >>entirety of the name space of a standard function to the library if
  17. >>the header is included.  If the programmer doesn't like this, then
  18. >>the programmer is permitted to simply declare the function required
  19. >>out of the standard library, and just use that.  Which your changes
  20. >>will also break.
  21.  
  22. >... I think that perhaps you are overreacting a
  23. >little, Jim. Could someone who has actually read (or written ;-) the changes
  24. >confirm that they would not break
  25. >    extern char *puts(const char *);
  26. >    inti main() { puts("Hello world\n"); return 0; }
  27. >?
  28.  
  29. Jim is correct on this point.  The change says that you must include a
  30. standard header for standard functions, and that the results of providing
  31. your own declarations are undefined.  The reasons for this are to allow
  32. implementors the freedom to use existing C libraries and declare the
  33. functions to be extern "C", or to write new library functions with C++
  34. linkage (or a mixture of both).  A portable program cannot assume what
  35. choice was made.  (I suppose the functions could use Fortran or PL/I
  36. linkage, for that matter.)
  37.  
  38. If an implementation uses the same library for C and C++, which is
  39. true for current implemenations, you can successfully do this:
  40.     extern "C" int puts(const char *);
  41.     int main() { puts("Hello world\n"); return 0; }
  42. You are just not assured the code will work.
  43.  
  44. Jim missing a point, I think.  Let's say, under his scenario, that I
  45. create a class with a member function getchar.  I am careful not to
  46. use <stdio.h>, and everything is fine.  A later programmer wants to use
  47. stdio as well as my class library, and the code won't compile.
  48.  
  49. We have (at least) two choices.  Jim wants to leave the C headers alone,
  50. meaning that the names of all the C library functions are unavailable
  51. for use as class member functions.  The choice which was adopted says
  52. that some existing C code would have to be modified under some C++
  53. implementations -- you might have to use standard headers instead of
  54. homebrew declarations of standard functions.  I don't think you can make
  55. a case that either choice is just plain wrong; it is a judgement call.
  56. The C++ Committee made a judgement, and anyone is free to disagree.
  57.  
  58. Jim also identified one "quiet change":  If you take the address of a
  59. standard library function in C, the address will compare equal across
  60. compilation units.  With the C++ change, inline versions of a standard
  61. function might (but might not) have different addresses in different
  62. compilation units.
  63.  
  64. A few weeks ago I asked for analyses of this situation, or of any other
  65. problem associated with the change in C library rules for C++.  I did
  66. not get any response.  I renew the request.  If the Committee has made
  67. a bad decision, this is the time to correct it.
  68. -- 
  69.  
  70. Steve Clamage, TauMetric Corp, steve@taumet.com
  71.