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: C++ and garbage collection
Message-ID: <57695@microsoft.UUCP>
Date: 24 Sep 90 21:22:55 GMT
References: <2030@aber-cs.UUCP>
Reply-To: jimad@microsoft.UUCP (Jim ADCOCK)
Organization: Microsoft Corp., Redmond WA
Lines: 23

In article <2030@aber-cs.UUCP> pcg@cs.aber.ac.uk (Piercarlo Grandi) writes:
|  There's at least one large interesting class of machines on which these
|  assumptions fail miserably.
|
|Maybe one can be clever enough to find a storage managemen scheme by which
|integer, string or float values are not easily mistaken with addresses also
|for this one large interesting (for marketing departments only, I surmise
|:->) class of machines -- or may be not.

I take it you don't find solving hard problems for a large number of
real world customers "interesting" ?

-- In any case, I think you mistake the problem.  On a few machines/os pairs
that are interesting from a "marketing" point of view, including Mac, Dos,
OS/2, Windows, etc, the pointer model chosen is often a 16:16 segment:offset
pair, rather than a 0:32-bit linear address.  This would not in itself be a 
fatal problem, except that segment and offset are frequently stored separately,
making "find all values that might be a valid object address" an N^2 problem.

|.... Especially if you can make the storage allocator and compiler
|cooperate.

If one has compiler cooperation, *why* would one use conservative approaches?