Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!microsoft!jimad From: jimad@microsoft.UUCP (Jim ADCOCK) Newsgroups: comp.object Subject: Re: Overhead in object tables Message-ID: <70647@microsoft.UUCP> Date: 13 Feb 91 17:31:09 GMT References: <11797@darkstar.ucsc.edu| <1913@media01.UUCP> <1991Feb6.111013.8412@tukki.jyu.fi> Reply-To: jimad@microsoft.UUCP (Jim ADCOCK) Organization: Microsoft Corp., Redmond WA Lines: 63 In article <1991Feb6.111013.8412@tukki.jyu.fi| sakkinen@jytko.jyu.fi (Markku Sakkinen) writes: |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++. I disagree -- but of course, this all depends exactly on how one defines the task of "enumerating all instances of a certain class." The general approach people typically take to solving this problem in C++ is to create a base class that supports the methods necessary to do the enumerating of "objects." If you want all "objects" to be enumerable, you put the necessary support in the base class of all "objects." The creator of a new class then needs to implement a few support functions for that particular class. Templates can typically reduce this to a one liner. If you want to do better than that, then you indeed need to make compiler changes, and/or support tools to automatically generate the support routines. In general, its do-able, and people are doing it, but it may not be quite as simple and clean today as people might like. |(Even if you by some means knew the boundaries of an object, |you would normally not be able to tell its class.) Depends on what one considers an "object." If all "objects" have vtables, then all are essentially type-tagged, and it is easy to tell classes. Or if all "objects" are segregated by pools, then its easy to tell from their pools. Of if all "objects" of a class are linked together .... |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. I don't believe C++ was designed for saving storage -- rather, I believe it was designed to be close to optimal in speed while using close to traditional compiler techniques. There are areas where C++ is not very efficient in the use of storage -- constructors, destructions, and the approach taken to method dispatch come to mind. Creating subclasses in C++ where only one or two virtual methods are overridden can be quite expensive of space. Hashed dispatch would be slower, but more space efficient under these conditions. |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. Could be, needn't be. Either the programmer has to do some programming to support this, in which case it wouldn't be an extension to the language, or the compiler would have to add the feature, in which case it would be an extension to the language.