home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / lang / cplus / 12950 < prev    next >
Encoding:
Text File  |  1992-08-26  |  2.6 KB  |  57 lines
  1. Newsgroups: comp.lang.c++
  2. Path: sparky!uunet!stanford.edu!EE.Stanford.EDU!sierra!mcgrant
  3. From: mcgrant@rascals.stanford.edu (Michael C. Grant)
  4. Subject: Re: the 'standard' complex class
  5. In-Reply-To: zougas@me.utoronto.ca's message of Thu, 27 Aug 1992 03:13:46 GMT
  6. Message-ID: <MCGRANT.92Aug26232210@rascals.stanford.edu>
  7. Sender: usenet@EE.Stanford.EDU (Usenet)
  8. Organization: Information Systems Laboratory, Stanford University
  9. References: <MCGRANT.92Aug26143400@rascals.stanford.edu> <BtMGyz.52A@me.utoronto.ca>
  10. Date: 26 Aug 92 23:22:10
  11. Lines: 44
  12.  
  13. In article <BtMGyz.52A@me.utoronto.ca> zougas@me.utoronto.ca (Tom Zougas) writes:
  14.  
  15.    mcgrant@rascals.stanford.edu (Michael C. Grant) writes:
  16.  
  17.    >Because the class does not need to be specially notified when the .re or
  18.    >.im fields change, why not make them public? It certainly allows for
  19.    >maximum flexibility; it won't break a single function already written
  20.    >for complex numbers.
  21.  
  22.    Don't forget that complex numbers could also be represented in polar form.
  23.    The point of abstraction is you don't want to know HOW the class is
  24.    represented only WHAT is available. 
  25.  
  26. I don't need that old tired line again. I understand the value of
  27. abstraction---of course that's true in general. But I have no desire
  28. whatsoever to have a complex ABSTRACT data type. I want a CONCRETE
  29. EFFICIENT data type. I want to know EXACTLY how the class is represented,
  30. because I can easily make design choices that way to improve efficiency.
  31. Despite the fact that even doubles are abstract data types, we really don't
  32. think of them as such. We can easily assign values to them, perform
  33. automatic type casts, etc. without worrying about which member function to
  34. use.
  35.  
  36. If I wanted a polar class I could certainly whip one up with the
  37. appropriate conversions to the standard complex class and so forth. And,
  38. if it weren't for the fact that the angle probably ought to be represented
  39. in fixed-point, I'd make its data members public too---because setting
  40. the value of .r or .theta wouldn't trigger a chain reaction of events
  41. as often happens in abstract data types.
  42.  
  43.    Inlining access functions might give
  44.    the efficiency you need.
  45.  
  46. Nope, unfortunately that's not true---the way AT&T set things up, that is.
  47. Their functions pass by value and not by reference, and from examining the
  48. assembly I can tell you that the efficiency isn't there, even for the
  49. inlined functions. Of course, when I manually changed appropriate functions
  50. to accept 'const complex&' instead of 'complex', that improved things a
  51. lot, but not quite to the point that I'm happy with keeping .re and .im
  52. private. 
  53.  
  54. Michael C. Grant
  55.  
  56.  
  57.