home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / lang / cplus / 18411 < prev    next >
Encoding:
Internet Message Format  |  1992-12-24  |  2.8 KB
  1. Path: sparky!uunet!synaptx!synaptics.com!daveg
  2. From: daveg@synaptics.com (Dave Gillespie)
  3. Newsgroups: comp.lang.c++
  4. Subject: Re: Sizeof and Virtual functions
  5. Message-ID: <DAVEG.92Dec24195757@synaptx.synaptics.com>
  6. Date: 25 Dec 92 03:57:57 GMT
  7. References: <1992Dec24.061254.9763@nuscc.nus.sg> <1992Dec24.132121.1@vax1.bham.ac.uk>
  8. Sender: daveg@synaptx.Synaptics.Com
  9. Organization: Synaptics, Inc., San Jose, CA
  10. Lines: 50
  11. In-reply-to: mccauleyba@vax1.bham.ac.uk's message of 24 Dec 92 13:21:21 GMT
  12.  
  13. In article <1992Dec24.132121.1@vax1.bham.ac.uk> mccauleyba@vax1.bham.ac.uk (Brian McCauley) writes:
  14.  
  15. >> Isn't there a better way to implement virtual functions ? 
  16. > No. The only other way would be to include the type information in the pointer
  17. > itself so all pointers to objects of classes with virtual functions would
  18. > become bigger. This would also mean that if a pointer were converted to void*
  19. > and back it would loose it's type information. (I'm not sure if a compiler
  20. > with this property would be conforming but it would certainly be unpopular).
  21.  
  22. Oh, surely you're not saying there is *no possible* other way to
  23. implement virtual functions than this.
  24.  
  25. Consider:  Suppose you divided your memory space into pages, say of
  26. size 1K.  Arrange so that a given page only contains objects of a
  27. single given class (with virtual functions).  Make a table that maps
  28. from page numbers onto virtual function tables.  If objects are small
  29. enough so that many can fit on a single page, the virtual overhead is
  30. essentially removed.  And in particular, the overhead is moved out of
  31. the object itself, so we've removed the effect on the value of `sizeof'.
  32.  
  33. (Now, this ignores the issue of stack allocation of objects, or
  34. inclusion of objects as members of other objects.  It would take
  35. a lot of work to iron out all the details, but my point is, it's
  36. *possible* to implement virtual functions in a totally different
  37. way if that's what you really need.)
  38.  
  39. > Another solution would be to adjust the action of the `sizeof' and `(void*)'
  40. > operators to refer to the object excluding its type indicator but
  41. > this would break any code that used `malloc'.
  42.  
  43. It would break all kinds of things, in fact.
  44.  
  45. >> Isn't the current implementation a clever hack at best ?
  46. > Possibly but the only alternative would be a clumsy hack.
  47.  
  48. Or something better that nobody's thought of, yet.
  49.  
  50. > Almost any use of void* and sizeof is implementation dependant, they are
  51. > really part of C and C++ programmers should avoid them whenever possible.  
  52.  
  53. An excellent point.  The `new' operator was a fine innovation in C++,
  54. even aside from its necessity when constructors are involved.  It
  55. removes the one place in C where `sizeof' was needed in everyday
  56. programs.
  57.  
  58.                                 -- Dave
  59. --
  60. Dave Gillespie
  61.   daveg@synaptics.com, uunet!synaptx!daveg
  62.   or: daveg@csvax.cs.caltech.edu
  63.