NetNews Usenet Archive 1992 #18/NN_1992_18.iso/spool/comp/lang/cplus/12614

Text File | 1992-08-19 | 3.7 KB | 88 lines

Newsgroups: comp.lang.c++
Path: sparky!uunet!mole-end!mat
From: [e-mail]
Subject: Re: Reference counting for vectors, (Tony Hansen's book).
Message-ID: <[e-mail]>
Summary: Backwards of Backwards, Representation .vs. Representee
Organization: :
References: <[e-mail]> <[e-mail]>
Date: Wed, 19 Aug 1992 17:53:00 GMT
Lines: 76

In article <[e-mail]>, [e-mail] (Thomas M. Breuel) writes:
> [e-mail] writes:

>    These value-is-the-only-thing-of-interest data structures (representation
>    schemes) are precisely those for which GC is needed and for which it is
>    well-suited.

> Also, you got it backwards. The need for true GC arises precisely when
> object identies (pointers, addresses, aliasing) matter. If only the
> value of an object matters, you can avoid the need for garbage
> collection trivially via copying or reference counting on assignment
> and initialization (although a real garbage collector is empirically
> still more efficient in most cases).

You are confusing representation with the thing represented.  What you
write is true of the objects-in-memory that represent the values.  But
when you look at the values that represent real-world entities, it's
the other way around.

GC-demanding algorithms are needed when

    1)    your space (or set, or domain) of Values-Representing-The-World
    is large (nearly infinite, or large enough not to be easily
    representable in the space represented by a couple of machine
    words), and

    2)    it's impossible to relate the lifetime over which a given
    value is needed to the lifetime of a single object (not Object)
    in the algorithms used, and

    3)    one copy of the representation-of-value is indistinguishable
    from another and carries no information about the things to
    which it is related

Property (1) means that fixed-length identifiers (integers, strings,
etc.) cannot be used.  (In fact, the value may be represented implicitly
by a composite of the data that it identifies--that is, we don't name
or store the value, but only the things that it maps to.)

Property (2) means that the value representation cannot be part of any
of the objects-in-memory that use it, nor part nor managed by of any of
the Objects that use it.

Property (3) means that there need be no single identity that represents
the value, but that the value can be represented as often as needed by
an object-in-memory identity, which may be the identity of a data structure
(or `information structure', or `objects-and-relationships') that contains
the information which the value identifies.  A value representation can
be created and destroyed as needed.

I'm afraid that the text above is excruciating to paw your way through.
It becomes quite a bit clearer if you draw _and understand_ the `pure'
E-R diagrams for the information in a problem whose algorithms demand GC.
(`Pure' in that there is no distinction between attributes and anything
else; they are all entities, and all the cardinalities are described.)

I suggest that any discussion as to the meaning of the above be carried
out on e-mail.  Any refutation, of course, can take place here.  But
please be specific, and be prepared to have your work inspected by
E-R model.

        Always start by drawing a free-body diagram.
            --Prof. Milton Stecher (in Physics 101 lecture).

        Draw your free-body diagram!
            --Prof. Milton Stecher (in consultation).

        You didn't draw your free-body diagram, did you?
            --Prof. Milton Stecher (in Physics 101 recitation).

Yes, I think that an E-R understanding can tell us that much!
--
 (This man's opinions are his own.)
 From mole-end                Mark Terribile

 [e-mail], Somewhere in Matawan, NJ