home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / lang / cplus / 12945 < prev    next >
Encoding:
Text File  |  1992-08-26  |  1.5 KB  |  36 lines
  1. Newsgroups: comp.lang.c++
  2. Path: sparky!uunet!cs.utexas.edu!torn!skule.ecf!drill.me!zougas
  3. From: zougas@me.utoronto.ca (Tom Zougas)
  4. Subject: Re: the 'standard' complex class
  5. Message-ID: <BtMGyz.52A@me.utoronto.ca>
  6. Sender: news@me.utoronto.ca (News Reader)
  7. Organisation: U of Toronto, Dept. of Mechanical Engineering
  8. Organization: UofT Mechanical Engineering
  9. References: <MCGRANT.92Aug26143400@rascals.stanford.edu>
  10. Date: Thu, 27 Aug 1992 03:13:46 GMT
  11. Lines: 23
  12.  
  13. mcgrant@rascals.stanford.edu (Michael C. Grant) writes:
  14.  
  15.  
  16. >I am rather frustrated with the approach that AT&T took with its complex
  17. >class, specifically the decision to make the real and imaginary fields
  18. >private. (GNU's libg++ makes them protected, which is similarly frustrating
  19. >but not quite as much so).
  20.  
  21. >Because the class does not need to be specially notified when the .re or
  22. >.im fields change, why not make them public? It certainly allows for
  23. >maximum flexibility; it won't break a single function already written
  24. >for complex numbers.
  25.  
  26. Don't forget that complex numbers could also be represented in polar form.
  27. The point of abstraction is you don't want to know HOW the class is
  28. represented only WHAT is available. Inlining access functions might give
  29. the efficiency you need.
  30.  
  31. -- 
  32. ===========================================================================
  33. Tom Zougas                          zougas@me.utoronto.ca
  34. Engineering Mechanics and Design Laboratory               416-978-1281
  35. Dept of Mechanical Engineering, University of Toronto,      Toronto, CANADA
  36.