Path: utzoo!attcan!uunet!snorkelwacker.mit.edu!bloom-beacon!eru!hagbard!sunic!news.funet.fi!tukki.jyu.fi!sakkinen From: sakkinen@tukki.jyu.fi (Markku Sakkinen) Newsgroups: comp.object Subject: Re: Overhead in object tables Message-ID: <1991Feb6.111013.8412@tukki.jyu.fi> Date: 6 Feb 91 11:10:13 GMT References: <11797@darkstar.ucsc.edu> <1913@media01.UUCP> Reply-To: sakkinen@jytko.jyu.fi (Markku Sakkinen) Organization: University of Jyvaskyla, Finland Lines: 30 In article moss@cs.umass.edu writes: >In article <1913@media01.UUCP> pkr@media01.UUCP (Peter Kriens) writes: > > The other advantage of an object table is the fact that you can enummerate > all the instances of a certain class. This can only be done when you > have an object table or link the objects (much harder). > >You can enumerate objects even *without* an object table if you make the heap >scannable. This is easy to do for Smalltalk, I expect more difficult to do for >C++ without a little additional overhead to help you find object boundaries >and such. It would not be a problem for our Modula-3 memory management system. I would believe that the task is _impossible_ for C++. (Even if you by some means knew the boundaries of an object, you would normally not be able to tell its class.) However, some extremely sophisticated implementation, completely different from the standard ones, might perhaps make it possible. Such an implementation should be focussed on a strong object orientation instead of saving storage. Of course the programmer-accessible feature for scanning through all existing instances of a given class would itself be an extension of the standard language. Markku Sakkinen Department of Computer Science and Information Systems University of Jyvaskyla (a's with umlauts) PL 35 SF-40351 Jyvaskyla (umlauts again) Finland SAKKINEN@FINJYU.bitnet (alternative network address) Brought to you by Super Global Mega Corp .com