home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / lang / c / 16056 < prev    next >
Encoding:
Text File  |  1992-11-07  |  3.4 KB  |  79 lines

  1. Newsgroups: comp.lang.c
  2. Path: sparky!uunet!charon.amdahl.com!pacbell.com!decwrl!sdd.hp.com!spool.mu.edu!wupost!uwm.edu!zaphod.mps.ohio-state.edu!uunet.ca!wildcan!sq!msb
  3. From: msb@sq.sq.com (Mark Brader)
  4. Subject: Re: Returned struct
  5. Message-ID: <1992Nov6.041315.17321@sq.sq.com>
  6. Organization: SoftQuad Inc., Toronto, Canada
  7. References: <1992Nov5.075611.14809@piccolo.cit.cornell.edu> <Bx9pJE.Et4@portal.hq.videocart.com>
  8. Date: Fri, 6 Nov 92 04:13:15 GMT
  9. Lines: 68
  10.  
  11.  
  12. Stephen Lee (sl14@crux3.cit.cornell.edu) writes:
  13. > : How can one make use of a struct returned by a function?  e.g.
  14. > : 
  15. > : struct complex complex_add(struct complex a, struct complex b);
  16. > : 
  17. > : I tried
  18. > : 
  19. > : struct complex z1, z2, z3;
  20. > : 
  21. > : z1.x = 0; z1.y = 3;
  22. > : z2.x = 5; z2.y = 4;
  23. > : 
  24. > : z3 = complex_add(z1, z2);
  25.  
  26. This looks correct, but it is not a complete program.  The most likely
  27. cause of the compiler's rejection of the code is that complex_add() was
  28. actually defined *after* the code that called it, or in a separate file,
  29. and no declaration of it was provided before the call in the same file
  30. as the call.  If the lines quoted above actually occurred in the same
  31. file in the order shown, and if struct complex actually contains members
  32. named x and y whose type is arithmetic, then the problem must lie some-
  33. where else in the program.
  34.  
  35. Dave Fuller (dfuller@portal.hq.videocart.com) responds:
  36.  
  37. > If indeed you want to use a return value, it should exist as a pointer
  38. > to the structure ...  passing structures around is not the right way to
  39. > deal with them, you need to pass them as pointers. Although some compilers
  40. > allow passing of structures, lets assume it will end up on one that doesn't
  41. > do this.
  42.  
  43. This reply of Dave's seems to have passed through some sort of time and
  44. causality warp.  Stephen's question uses function prototype syntax, which
  45. was introduced into C at the time of the ANSI standardization in the late
  46. 1980s.  Dave's article plainly shows by its content that it was written
  47. much earlier, in the 1970s or early 1980s.  Yet it shows up today, in 1992,
  48. *as* *a* *followup* to Stephen's question.  How on Earth is this possible?
  49. Followups to rec.arts.sf.misc. :-)
  50.  
  51.  
  52. H'rm.
  53. The point is that, as the FAQ says (you have read it, Dave?), the passing
  54. and assigning of structs has been part of C for something like 14 years
  55. now, and most people now consider it reasonable to assume that they'll
  56. never again see a compiler that doesn't support it.  The earliest C
  57. compilers didn't support "unsigned short" or "unsigned long" either --
  58. should we avoid those data types?  No; that'd be silly today.
  59.  
  60. If one is going to criticize Stephen's code for non-portability to older
  61. implementations, then the one thing that must be seriously mentioned is
  62. the use of function prototypes.  There are still quite a few compilers out
  63. there that are over 5 years old and which will throw syntax error fits
  64. when they see
  65.  
  66.     struct complex complex_add(struct complex a, struct complex b);
  67.  
  68. If the compiler's diagnostic had related to syntax rather than being
  69. "illegal structure operation", and if the compiler wasn't mentioned as
  70. being related to a C++ implementation, I would suspect that that was what
  71. was going on here.  As it is, I can't say what is wrong; I can only say
  72. what is right.
  73. -- 
  74. Mark Brader            "Nicely self-consistent. (Pay no attention to
  75. SoftQuad Inc., Toronto         that D-floating number behind the curtain!)"
  76. utzoo!sq!msb, msb@sq.com            -- Chris Torek, on pasta
  77.  
  78. This article is in the public domain.
  79.