home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / lang / cplus / 12932 < prev    next >
Encoding:
Text File  |  1992-08-26  |  2.8 KB  |  59 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: the 'standard' complex class
  5. Message-ID: <MCGRANT.92Aug26143400@rascals.stanford.edu>
  6. Sender: usenet@EE.Stanford.EDU (Usenet)
  7. Organization: Information Systems Laboratory, Stanford University
  8. Date: 26 Aug 92 14:34:00
  9. Lines: 48
  10.  
  11.  
  12. I am rather frustrated with the approach that AT&T took with its complex
  13. class, specifically the decision to make the real and imaginary fields
  14. private. (GNU's libg++ makes them protected, which is similarly frustrating
  15. but not quite as much so).
  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. It also seems silly that in <math.h> we have
  23.    double log( double );
  24. but in <complex.h> it is declared as a friend function:
  25.    friend complex log( complex )
  26.  
  27. I rarely if ever use public data members in my classes. But, if there is no
  28. need for my class to 'know' that a member was changed (if I don't change
  29. my behavior based on that field, and if I don't need to check if its value
  30. is legal, for instance), often I just make it public. I say 'often' because
  31. sometimes in the effort of providing a consistent interface I supply set 
  32. and get methods for those fields too.
  33.  
  34. In this case, though, there are only TWO fields, in a class whose behavior
  35. is invariant to changes in those fields, whose values you cannot assign
  36. 'illegal' values. I suppose complex infinites and NaN's are a tricky issue
  37. but to handle them inside the class would be to slow things down way too
  38. much anyway. So, I see no reason besides some overly-dogmatic
  39. information-hiding argument to keep the fields private
  40.  
  41. I'm complaining because I'm trying to really tighten some inner loops in my
  42. code (routines on the level of BLAS). Having to go through the various
  43. public double->complex conversions, plus the fact that because complex is
  44. two doubles wide and can't be stored in a register, hinder the optimization.
  45. When I open up the complex class by altering the header file, I can easily
  46. make things just as fast as I expect they can be by allowing me to treat
  47. the real and complex fields separately. Since this is supposed to act like
  48. a basic data type, these optimization differences should not occur; and,
  49. if making the fields public and letting me treat them individually is the
  50. way to make things faster, I say so be it.
  51.  
  52. Well, I have said way too much on this simple issue. I'd like to hear
  53. some other opinions. Believe me, I virutally never use public data fields,
  54. so I am indeed advocating this as more of an exception rather than the
  55. rule. What does everyone else think?
  56.  
  57. Michael C. Grant
  58.  
  59.