home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / lang / cplus / 12335 < prev    next >
Encoding:
Text File  |  1992-08-13  |  2.5 KB  |  70 lines
  1. Newsgroups: comp.lang.c++
  2. Path: sparky!uunet!mole-end!mat
  3. From: mat@mole-end.matawan.nj.us
  4. Subject: Re: Covariant Types in Derived Classes
  5. Message-ID: <1992Aug13.162956.10279@mole-end.matawan.nj.us>
  6. Summary: (Open request to Bjarne, ARK, and other Gurus)
  7. Organization: :
  8. References: <1992Aug8.210716.14741@ucc.su.OZ.AU> <713504630snx@trmphrst.demon.co.uk>
  9. Date: Thu, 13 Aug 1992 16:29:56 GMT
  10. Lines: 58
  11.  
  12. I'm afraid we are victims of diverging terminology here.
  13.  
  14. Let's try to get some convergence:
  15.  
  16.         Conversion:  The creation of a value in one type
  17.             corresponding _somehow_ to a value in
  18.             another type.  (Exception, sort of:  A
  19.             conversion to  void  in C or C++ creates a
  20.             _lack of a value_ corresponding vacuously to
  21.             a value in another type.  A zero-to-every
  22.             mapping, so to speak.)
  23.  
  24.         Cast: A C and C++ construct that can demand either
  25.             a conversion _within_ the type system
  26.             (e.g.  (int) 3.14159 ) or a conversion that
  27.             bypasses the type system (e.g  (char*) 0x30EA ).
  28.  
  29. In article <713504630snx@trmphrst.demon.co.uk>, nikki@trmphrst.demon.co.uk (Nikki Locke) writes:
  30. > In article <1992Aug8.210716.14741@ucc.su.OZ.AU> maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:
  31. > > In article <713221684snx@trmphrst.demon.co.uk> nikki@trmphrst.demon.co.uk (Nikki Locke) writes:
  32.  
  33. > > >No - some casts are fine - e.g. ...
  34. > > >Casting a built-in arithmetic type to a larger type to avoid arithmetic 
  35. > > >  overflow.
  36. > >     This is NOT a cast (in my terminology), but a value producting
  37. > > conversion. ...
  38.  
  39. Mercy even for Pooh-Bah!
  40.  
  41.     Open letter to the Gurus of C++:  Is there a preferred
  42.     terminology for expressing `this stuff'?  Can one be
  43.     created for the present need?  There's been more than one
  44.     discussion locked in violent agreement for want of it.
  45.  
  46. > By the way, what is 
  47. >     int x;
  48. >     long z;
  49. >     
  50. >     x = (int)z;
  51. > 
  52. > Is this a cast, or a conversion ? (I want a warning anyway, please).
  53.  
  54. It is a conversion that is indicated syntactically by a cast.  
  55.  
  56. Why do you want a warning?  You asked for it explicitly and it lies
  57. within the type system.  There's an important principle here: for
  58. every construct that can produce a warning, there must be a way to
  59. write an equivalent construct that does _not_ produce the warning.
  60. This is part and parcel of the C/C++ philosophy that ``if you _really_
  61. want to do that, we'll take you at your word.''
  62.  
  63. The code fragment written _without_ the cast might very well merit a
  64. warning about value truncation.
  65. -- 
  66.  (This man's opinions are his own.)
  67.  From mole-end                Mark Terribile
  68.  
  69.  mat@mole-end.matawan.nj.us, Somewhere in Matawan, NJ
  70.