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

Text File | 1992-08-15 | 3.0 KB | 68 lines

Newsgroups: comp.lang.c++
Path: sparky!uunet!munnari.oz.au!metro!extro.ucc.su.OZ.AU!maxtal
From: [e-mail] (John MAX Skaller)
Subject: Re: Garbage Collection for C++
Message-ID: <[e-mail]>
Sender: [e-mail]
Nntp-Posting-Host: extro.ucc.su.oz.au
Organization: MAXTAL P/L C/- University Computing Centre, Sydney
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Sun, 16 Aug 1992 05:45:19 GMT
Lines: 55

In article <[e-mail]> [e-mail] (Dave Gillespie) writes:
>In article <[e-mail]> [e-mail] (Bob Cannard @ PCB x5565) writes:

>I still think declaring pointers to be GC would be too much of a
>hassle for the programmer, so we're left having to assume all
>pointers may point to GC-allocated objects.

    Thats why GC on a class basis. A pointer to a GC class
IS a GC pointer, there's no need for the programmer to 'declare'
it as such.

    GC class X { .... // GC collectable class
    X* p;    // GC pointer because X is GC, no special syntax


>Without adding lots of
>tags in places that make C compatiblity awkward, we're left with a
>completely "conservative", i.e., brute-force GC algorithm.  We scan
>every word on the stack, every word in static storage, and every
>word on the non-GC heap for things that look like GC pointers.

    It wont work under Windows.
There is no stack, except temporarily on member function calls.
The objects are rooted directly in the window memory, and the're
looked after by the OS, not the stack.

    The C memory model is defunct. This is the biggest flaw
in C/C++. C memory model assumes three segments: code, data, stack.
(Pascal assume two, code and stack). We can tack on the heap for
C++ because it has a built in 'new' operator. To implement
persistence, dynamic linkage, multi-tasking with shared memory,
ROM, hardware ports, etc, requires language support.
(Oh, C has register too)

    If you look at the Windows memory model you will see what I mean.
It requires truly awful C to manage, and C++ cant help much.
Windows uses handles, and you have to lock them to get out a pointer.
The memory can be moved when the handle is not locked. And you had
better unlock them after you're finished.

    Smart pointers can be used to do the lock automatically,
but I cant see how the unlock can be done, operator-> just
isn't smart enough. Basically, the C/C++ memory model doesn't
support handles, and so NO amount of cleverness can convince
the system to support handles. You have to do it by hand.

    Anyhow, looking GC certainly raises some interesting
questions. It generally get implemented in systems with a controlled
run-time environment, which definitely isnt C++.

--
;----------------------------------------------------------------------
        TIM (TAL) LISTER,         [e-mail]
    Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------