home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / lang / cplus / 15996 < prev    next >
Encoding:
Internet Message Format  |  1992-11-09  |  3.3 KB
  1. Xref: sparky comp.lang.c++:15996 comp.std.c++:1523
  2. Path: sparky!uunet!sun-barr!decwrl!spool.mu.edu!darwin.sura.net!tulane!uflorida!travis.csd.harris.com!amber!bill
  3. From: bill@amber.csd.harris.com (Bill Leonard)
  4. Newsgroups: comp.lang.c++,comp.std.c++
  5. Subject: Re: PROPOSAL: Hidden private parts of classes
  6. Message-ID: <1dmed7INNk5f@travis.csd.harris.com>
  7. Date: 9 Nov 92 19:32:55 GMT
  8. References: <1992Oct30.113234.15010@daimi.aau.dk> <1csnjaINNqa0@hpsdlss3.sdd.hp.com> <klamer.720538594@mi.el.utwente.nl> <1992Nov7.155248.23401@ucc.su.OZ.AU> <klamer.721303355@mi.el.utwente.nl>
  9. Distribution: ssd
  10. Organization: Harris CSD, Ft. Lauderdale, FL
  11. Lines: 52
  12. NNTP-Posting-Host: amber.ssd.csd.harris.com
  13.  
  14. In article <klamer.721303355@mi.el.utwente.nl>, klamer@mi.el.utwente.nl (Klamer Schutte) writes:
  15. > 
  16. > I doubt it. I can't see how a compiler can build a stack frame with
  17. > auto variables, if the sizes of the elements on the stack frame are
  18. > unknown. What can be done, is putting a pointer to the actual data in
  19. > the stack frame, and allocate the data element itself on some heap
  20. > (preferably a fast one, like alloca()). 
  21. > 
  22. > Otherwise the offsets of individual elements in the stack frame are unknown
  23. > at compile time. These might be patched back at link time. (seems dirty
  24. > to me). Allowing this you might loose some optimization opportunities.
  25.  
  26. Why do stack frames have to be fixed size?  Many languages, including Ada,
  27. allow for automatic objects whose size is determined at runtime.  This is
  28. not new technology, nor even all that hard.  In most implementations, the
  29. compiler allocates a fixed-size part of the frame for its own use (like
  30. register saving and such), plus all the known-sized automatic objects.  It
  31. then computes the amount of space needed for variable-sized objects and
  32. extends the stack frame by that amount.
  33.  
  34. In some languages, like Ada for instance, variable-sized objects can even
  35. be declared in nested blocks and/or returned from functions!  This means
  36. that the stack frame must grow and shrink as the function executes.  That
  37. gets a little more complicated, but again, the technology is not new.
  38.  
  39. I think the clever thing to do for C++ would be to make the sizeof operator
  40. be specifiable by the user, with arguments specified after the constructor
  41. arguments, say.  For instance:
  42.  
  43.     Foo   * x = new Foo(/* constructor args */) (/* sizeof args */) ;
  44.  
  45. The built-in sizeof operator would automatically generate a function if the
  46. size of the object is not known at compile-time.  This would necessitate,
  47. of course, some way to indicate that you wanted to defer the complete
  48. specification of the class in its declaration, and also some way to
  49. complete that specification elsewhere.
  50.  
  51. As much as I would like to see this feature, though, I wouldn't argue for
  52. its inclusion in the current standard.  Defer it until the next revision,
  53. perhaps.  The standard has dragged on long enough -- it certainly has
  54. enough in it to be useful (as evidenced by the large number of C++ users
  55. already).
  56.  
  57. -- 
  58. Bill Leonard
  59. Harris Computer Systems Division
  60. 2101 W. Cypress Creek Road
  61. Fort Lauderdale, FL  33309
  62. bill@ssd.csd.harris.com
  63. ---------------------------------------------------------------------------
  64. Prism: A place for light waves that commit minor refractions.
  65. ---------------------------------------------------------------------------
  66.