home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / std / cplus / 1900 < prev    next >
Encoding:
Text File  |  1992-12-23  |  3.0 KB  |  66 lines
  1. Path: sparky!uunet!cs.utexas.edu!geraldo.cc.utexas.edu!slcs.slb.com!ut-emx!jamshid
  2. From: jamshid@ut-emx.uucp (Jamshid Afshar)
  3. Newsgroups: comp.std.c++
  4. Subject: Re: Must derived class reserve space for an empty base class?
  5. Summary: don't now, but I still have shopping to do
  6. Message-ID: <85744@ut-emx.uucp>
  7. Date: 23 Dec 92 06:27:30 GMT
  8. References: <1992Dec16.202800.3398@microsoft.com> <5450@holden.lulea.trab.se>
  9. Organization: The University of Texas at Austin; Austin, Texas
  10. Lines: 53
  11.  
  12. In article <5450@holden.lulea.trab.se> jbn@lulea.trab.se (Johan Bengtsson) writes:
  13. >Jim Adcock (jimad@microsoft.com) wrote:
  14. >: On the contrary, requiring unnecessary and unexpected padding within
  15. >: structures just to meet your new requirements would be extremely 
  16. >: undesirable, in my opinion.
  17. >
  18. >But the cases where "unnecessary" padding would be required would
  19. >have very minor impact on the majority of programs, at least if I
  20. >may consider the current implementation of virtuals (vtbl).  After all,
  21. >inheriting from a truly empty base class (no virtuals) is quite uncommon,
  22. >don't you think?
  23.  
  24. The fact the following idiom works under all current C++
  25. implementations, and that it will probably continue to work no matter
  26. what ANSI says, is what most worries me and why I originally posted
  27. this question.  Programmers will continue to do things like
  28.     class Register {
  29.        Set<Register*> alive;
  30.     protected:
  31.        Register() { alive += this; }
  32.        virtual ~Register() { alive -= this; }
  33.        static void foo();  // do something to all registered objects
  34.     };
  35.  
  36. If a special-case rule is not added making the above safe on *any* C++
  37. implementation, I hope more C++ literature will point out the fact
  38. that the above idiom is incorrect.  I've been doing stuff like this
  39. for years and never gave it a second thought.  I guess the correct way
  40. to do this would be to always add a dummy char to empty base classes,
  41. but then that's a waste on existing implementations.  Besides, if we
  42. are all going to do this, then why not instead make the compiler do it
  43. -- it could do a much better job of determining when padding is
  44. necessary.
  45.  
  46. >If pointer distinctness (as defined above) allows useful semantic constructs,
  47. >such as the very common idiom for operator=:
  48. >"if ( &other == this ) return", then a small and rare storage overhead
  49. >in examples such as the one below could easily be tolerated (IMHO).
  50.  
  51. I hadn't thought about this situation.  I'm sure there are many other
  52. cases besides operator=() where a member function wants to know if
  53. 'this' compares equal to the address of a parameter.  Yes, I know
  54. there are many cases when the address of two distinct objects compare
  55. equal when cast to |void*|, but as far as I know this is the only
  56. situtation where the address of two distinct objects compare equal
  57. without the aid of an eye-catching cast.
  58.  
  59. I'm still not sure how I feel about this situation.  I'm going to take
  60. a closer look at my code after the holidays to see how often I
  61. erroneously assume that when two EmptyAbstractClass*'s compare equal
  62. they are both pointing to the same object.
  63.  
  64. Jamshid Afshar
  65. jamshid@emx.utexas.edu
  66.