Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!wuarchive!gem.mps.ohio-state.edu!usc!orion.oac.uci.edu!uci-ics!rfg From: rfg@ics.uci.edu (Ron Guilmette) Newsgroups: comp.lang.c++ Subject: Re: multiple destructors Message-ID: <1989Oct27.165311.13662@paris.ics.uci.edu> Date: 27 Oct 89 23:53:12 GMT References: <1989Sep30.190719.3340@polyslo.CalPoly.EDU> <6590273@hplsla.HP.COM> <1989Oct19.022635.123@sdti.com> <1989Oct21.182759.13138@paris.ics.uci.edu> <1989Oct24.022726.2303@sdti.com> Reply-To: Ron Guilmette Organization: University of California, Irvine - Dept of ICS Lines: 29 In article <1989Oct24.022726.2303@sdti.com> wmm@sdti.SDTI.COM (William M. Miller) writes: >In article <1989Oct21.182759.13138@paris.ics.uci.edu> Ron Guilmette writes: >>There is (I believe) a simple solution. On most UNIX systems, the actual >>memory areas occupied by automatic (stack) variables, static variables, >>and "heap" variables are all different. If you can get the starting and/or >>ending addresses of these memory areas (and you usually can) then a quick >>comparison of the address of a given object to these addresses will tell you >>which area it is in. > >This is not portable to non-Unix systems, so I'm afraid it's an even dirtier >trick than setting a flag in the allocated space. (I'm using DOS and OS/2, >for example.) Thanks for the thought, though. Bothe Bjarne and you are getting on my case because this ain't portable (and because it will not work if you are in a multi-threaded system). Cut me some slack guys! I never said it was portable! It is just *a* solution. It is better than the big nothing that the language gives you if you *must* know what area an object is actually resident in. P.S. I'll bet that I can "port" this method you your XYZ system in less than 15 minutes (as long as the code which figures out what area an object is in is nicely confined to one little area of your program). As a matter of fact, I'll bet that I could easily write an automatic configurator routine which would (on startup) adapt to any arbitrary layout of stack/heap/static areas. Does anybody believe that this would be hard? If so, I'll be happy to prove you wrong. // rfg