home *** CD-ROM | disk | FTP | other *** search
- 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
- From: chased@rbbb.Eng.Sun.COM (David Chase)
- Newsgroups: comp.std.c++
- Subject: Re: Use of nested functions
- Date: 12 Jan 1993 23:02:09 GMT
- Organization: Sun
- Lines: 25
- Message-ID: <ll6jfhINN6n3@exodus.Eng.Sun.COM>
- References: <1993Jan9.182938.16874@ucc.su.OZ.AU> <1993Jan11.215111.11291@qualcomm.com>
- NNTP-Posting-Host: rbbb
-
- In article <1993Jan11.215111.11291@qualcomm.com> greg@harvey.qualcomm.com (Greg Noel) writes:
- >Recursion implies that the context of a pointer must be kept as part of
- >the pointer, which leads to either expanding the size of a function pointer
- >or generating trampoline code dynamically. Expanding function pointers
- >would be a cost even when nested functions are not used and there are
- >some architectures where code cannot be generated on the fly.
-
- I know that code can be generated on the fly on Sparc, 680x0, and
- 80286, 80386, 80486, PDP-11, VAX, 6502, and IBM 370. What
- architecture were you thinking of?
-
- Given such an architecture, are you sure that its problems cannot be
- treated by keeping a cache of generated code fragments (you keep a
- per-thread cache of code+data pairs to avoid the cost of page
- remapping and cache flushing). Remember, most machines ARE able to
- load programs and run them, so they must have some rudimentary ability
- to "generate" code at run-time.
-
- In truth, I don't high hopes for nested functions appearing in C++,
- but arguments against them based on their "cost" or "difficulty of
- implementation" are not very strong.
-
- David Chase
- Sun
-
-