home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / lang / cplus / 13395 < prev    next >
Encoding:
Text File  |  1992-09-08  |  2.7 KB  |  79 lines
  1. Newsgroups: comp.lang.c++
  2. Path: sparky!uunet!taumet!steve
  3. From: steve@taumet.com (Steve Clamage)
  4. Subject: Re: defining cast operators outside classes
  5. Message-ID: <1992Sep8.173613.25113@taumet.com>
  6. Organization: TauMetric Corporation
  7. References: <TMB.92Sep7162324@arolla.idiap.ch>
  8. Date: Tue, 8 Sep 1992 17:36:13 GMT
  9. Lines: 68
  10.  
  11. tmb@arolla.idiap.ch (Thomas M. Breuel) writes:
  12.  
  13. >Apparently, it is impossible to define a conversion operator for a
  14. >class without making the conversion operator a member function.
  15.  
  16. >It would be very useful to be able to define something like the
  17. >following without having to modify either class MyMatrix or class
  18. >TheirMatrix:
  19.  
  20. >    operator MyMatrix(TheirMatrix &m) {
  21. >        ...
  22. >    }
  23.  
  24. >Why was this seemingly arbitrary restriction made? Can it be
  25. >eliminated in the next version of C++?
  26.  
  27. In general, those operators which must be class members have that
  28. restriction to reduce the chance of subtle but serious bugs.
  29.  
  30. Consider operator+().  If we write x+y, where x or y has a class
  31. type, and no operator+ is visible, the code will not compile.  You
  32. must make a declaration visible.  There is nothing subtle or
  33. dangerous about this.
  34.  
  35. In the case of some operators you run the risk of having legal code
  36. with different meanings depending on whether the operator declaration
  37. is visible.  In the case of user-defined conversions, consider this:
  38.  
  39. class X {
  40.     public:
  41.     operator int();
  42. };
  43.  
  44. X x;
  45. double y = x;
  46.  
  47. extern operator double(const X&);    // not legal
  48. double z = x;
  49.  
  50. In this case, y gets "(double) X::operator int(x)",
  51. while z gets "operator double(x)".
  52.  
  53. The semantics depend on which non-class declarations are visible,
  54. which is not normally the case in C++.  (There is a somewhat
  55. parallel case:  You omit one overloaded function declaration and
  56. an unintended function is called.  Maybe someone can think of a way
  57. to solve that problem in the language.)
  58.  
  59. In the case of conversions, it is likely that the conversion function
  60. would need to be a friend function, thus needing to appear in the
  61. class definition anyway.
  62.  
  63. If you need to create an ad-hoc conversion from class A to class B
  64. when you don't own class A, you can make a B constructor taking an A.
  65. If you don't own class B either, you can write an ordinary function
  66. which does the conversion.
  67.  
  68. In the end, the restriction elminates a source of dangerous but subtle
  69. bugs while creating virtually no extra inconvenience.  The only
  70. inconvenience I can see occurs when ALL of these are met simultaneously:
  71.     - You need to convert an A to a B.
  72.     - You can't modify A or B.
  73.     - Everything needed to do the conversion is public.
  74.     - You want implicit conversion, not "b = A_to_B(a)".
  75. -- 
  76.  
  77. Steve Clamage, TauMetric Corp, steve@taumet.com
  78. Vice Chair, ANSI C++ Committee, X3J16
  79.