home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / lang / cplus / 13579 < prev    next >
Encoding:
Internet Message Format  |  1992-09-13  |  1.5 KB
  1. Path: sparky!uunet!pmafire!news.dell.com!natinst.com!cs.utexas.edu!sun-barr!olivea!bu.edu!att!att!allegra!alice!ark
  2. From: ark@alice.att.com (Andrew Koenig)
  3. Newsgroups: comp.lang.c++
  4. Subject: Re: zero-length datatype
  5. Message-ID: <23661@alice.att.com>
  6. Date: 13 Sep 92 15:19:04 GMT
  7. References: <23654@alice.att.com> <1992Sep11.185505.17536@cadsun.corp.mot.com> <23659@alice.att.com> <TMB.92Sep12212903@arolla.idiap.ch>
  8. Reply-To: ark@alice.UUCP ()
  9. Distribution: comp
  10. Organization: AT&T Bell Laboratories, Murray Hill NJ
  11. Lines: 20
  12.  
  13. In article <TMB.92Sep12212903@arolla.idiap.ch> tmb@idiap.ch writes:
  14.  
  15. > Well, it might be good to remain compatible, in the sense that every
  16. > object that has non-zero size in ISO C also have a non-zero size in
  17. > C++. However, since there are no objects of type "void" (or of some
  18. > other, newly introduced, distinguished type with zero size) in ISO C,
  19. > there can't be any harm in letting objects of this new type have zero
  20. > size: the behavior of existing code would not be affected.
  21.  
  22. That is not quite true, especially in the presence of templates.
  23.  
  24. I expect that there will be some committee members who will say
  25. that they want to be able to assume that objects of any type at all
  26. are nonzero in size and admitting a new empty type would violate
  27. that assumption.  And indeed it might even affect old C code, if that
  28. code uses a type that is macro-expanded into something not known until
  29. the code is actually compiled.
  30. -- 
  31.                 --Andrew Koenig
  32.                   ark@europa.att.com
  33.