home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / lang / cplus / 12953 < prev    next >
Encoding:
Text File  |  1992-08-26  |  1.8 KB  |  43 lines
  1. Newsgroups: comp.lang.c++
  2. Path: sparky!uunet!munnari.oz.au!cs.mu.OZ.AU!munta.cs.mu.OZ.AU!fjh
  3. From: fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON)
  4. Subject: Re: the 'standard' complex class
  5. Message-ID: <9224017.22289@mulga.cs.mu.OZ.AU>
  6. Sender: news@cs.mu.OZ.AU
  7. Organization: Computer Science, University of Melbourne, Australia
  8. References: <MCGRANT.92Aug26143400@rascals.stanford.edu> <BtMGyz.52A@me.utoronto.ca> <MCGRANT.92Aug26232210@rascals.stanford.edu>
  9. Date: Thu, 27 Aug 1992 07:21:24 GMT
  10. Lines: 31
  11.  
  12. mcgrant@rascals.stanford.edu (Michael C. Grant) writes:
  13.  
  14. >   Inlining access functions might give
  15. >   the efficiency you need.
  16. >
  17. >Nope, unfortunately that's not true---the way AT&T set things up, that is.
  18. >Their functions pass by value and not by reference, and from examining the
  19. >assembly I can tell you that the efficiency isn't there, even for the
  20. >inlined functions. Of course, when I manually changed appropriate functions
  21. >to accept 'const complex&' instead of 'complex', that improved things a
  22. >lot, but not quite to the point that I'm happy with keeping .re and .im
  23. >private. 
  24. >
  25. >Michael C. Grant
  26.  
  27. Sounds like you should be blaming your compiler's poor optimization,
  28. not the fact that .re and .im are private. If you have inline set_real()
  29. and set_imag() methods then you should get exactly the same code using
  30. them as using the private members.
  31.  
  32. Maybe you could post a specific example of some code that would be more
  33. efficient if you could use the private members.
  34.  
  35. Ah... I see from looking at <complex.h> that set_real() and set_imag()
  36. methods have NOT been provided by AT&T.
  37.  
  38. -- 
  39. Fergus Henderson             fjh@munta.cs.mu.OZ.AU      
  40. This .signature virus is a self-referential statement that is true - but 
  41. you will only be able to consistently believe it if you copy it to your own
  42. .signature file!
  43.