home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / std / cplus / 2036 < prev    next >
Encoding:
Internet Message Format  |  1993-01-12  |  1.6 KB

  1. Path: sparky!uunet!zaphod.mps.ohio-state.edu!howland.reston.ans.net!paladin.american.edu!darwin.sura.net!haven.umd.edu!ames!sun-barr!news2me.EBay.Sun.COM!exodus.Eng.Sun.COM!rbbb!chased
  2. From: chased@rbbb.Eng.Sun.COM (David Chase)
  3. Newsgroups: comp.std.c++
  4. Subject: Re: Use of nested functions
  5. Date: 12 Jan 1993 23:02:09 GMT
  6. Organization: Sun
  7. Lines: 25
  8. Message-ID: <ll6jfhINN6n3@exodus.Eng.Sun.COM>
  9. References: <1993Jan9.182938.16874@ucc.su.OZ.AU> <1993Jan11.215111.11291@qualcomm.com>
  10. NNTP-Posting-Host: rbbb
  11.  
  12. In article <1993Jan11.215111.11291@qualcomm.com> greg@harvey.qualcomm.com (Greg Noel) writes:
  13. >Recursion implies that the context of a pointer must be kept as part of
  14. >the pointer, which leads to either expanding the size of a function pointer
  15. >or generating trampoline code dynamically.  Expanding function pointers
  16. >would be a cost even when nested functions are not used and there are
  17. >some architectures where code cannot be generated on the fly.
  18.  
  19. I know that code can be generated on the fly on Sparc, 680x0, and
  20. 80286, 80386, 80486, PDP-11, VAX, 6502, and IBM 370.  What
  21. architecture were you thinking of?
  22.  
  23. Given such an architecture, are you sure that its problems cannot be
  24. treated by keeping a cache of generated code fragments (you keep a
  25. per-thread cache of code+data pairs to avoid the cost of page
  26. remapping and cache flushing).  Remember, most machines ARE able to
  27. load programs and run them, so they must have some rudimentary ability
  28. to "generate" code at run-time.
  29.  
  30. In truth, I don't high hopes for nested functions appearing in C++,
  31. but arguments against them based on their "cost" or "difficulty of
  32. implementation" are not very strong.
  33.  
  34. David Chase
  35. Sun
  36.  
  37.