home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / lang / cplus / 11521 < prev    next >
Encoding:
Internet Message Format  |  1992-07-25  |  1.4 KB

  1. Xref: sparky comp.lang.c++:11521 comp.std.c++:951
  2. Newsgroups: comp.lang.c++,comp.std.c++
  3. Path: sparky!uunet!mole-end!mat
  4. From: mat@uunet.uu.net!mole-end
  5. Subject: Re: Language extensions for run-time type identification
  6. Message-ID: <1992Jul25.071125.4141@uunet.uu.net!mole-end>
  7. Summary: Yeah, that's it--BREAK CODE!
  8. Organization: :
  9. References: <1992Jul21.143131.6902@cadsun.corp.mot.com> <1992Jul23.200803.22371@ucc.su.OZ.AU>
  10. Date: Sat, 25 Jul 1992 07:11:25 GMT
  11. Lines: 20
  12.  
  13. In article <1992Jul23.200803.22371@ucc.su.OZ.AU>, maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:
  14. > In article <1992Jul22.212111.12530@taumet.com> steve@taumet.com (Steve Clamage) writes:
  15.  
  16. > >We could patch this up by saying you have to use 'class' rather than
  17. > >'struct' to get RTTI, but this would break existing C++ code which
  18. > >relies on the equivalence of 'struct' and 'class'.  Maybe this is
  19. > >not too high a penalty, but it would have to be carefully considered.
  20.  
  21. >     IMHO making struct == class (baring access defaults) was a poor
  22. > decision. I would much rather 'struct' MEANT C-compatible. 
  23. > So I would not be dismayed at the change suggested above.
  24.  
  25. You wouldn't, but I would.  That's an awfully high-priced change.  And I
  26. think that there are a few hundred million lines of C++ in the various
  27. programs that would be affected.
  28. -- 
  29.  (This man's opinions are his own.)
  30.  From mole-end                Mark Terribile
  31.  
  32.  uunet!mole-end!mat, Somewhere in Matawan, NJ
  33.