From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=0.2 required=5.0 tests=BAYES_00,HEADER_SPAM,
	REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: fc772,b30bd69fa8f63cb2
X-Google-Attributes: gidfc772,public
X-Google-Thread: 103376,b30bd69fa8f63cb2
X-Google-Attributes: gid103376,public
X-Google-ArrivalTime: 2003-06-21 12:39:04 PST
Path: 
 archiver1.google.com!news1.google.com!newsfeed.stanford.edu!logbridge.uoregon.edu!uwm.edu!rpi!not-for-mail
From: brangdon@cix.co.uk (Dave Harris)
Newsgroups: comp.lang.ada,comp.lang.c++.moderated
Subject: Re: C bug of the day
Date: 21 Jun 2003 15:41:17 -0400
Organization: unknown
Sender: cppmods@netlab.cs.rpi.edu
Message-ID: <memo.20030621140227.60519A@brangdon.madasafish.com>
References: <7gBHa.12174$KF1.273806@amstwist00>
Reply-To: brangdon@cix.co.uk
NNTP-Posting-Host: netlab.cs.rpi.edu
X-Original-Date: Sat, 21 Jun 2003 14:02 +0100 (BST)
X-Submission-Address: c++-submit@netlab.cs.rpi.edu
X-Auth: PGPMoose V1.1 PGP comp.lang.c++.moderated
	iQBVAwUAPvS010HMCo9UcraBAQGVCQH/dQr/5QqhaTnHsP+n4TusbS7jqnuom/rJ
	UUbqeIHH8Zy5TVqcNjby53cv/SGXWUQ4QYl52wSJ9jd8aG8IGT2/fw==
	=wnny
Xref: archiver1.google.com comp.lang.ada:39537 comp.lang.c++.moderated:68883
Date: 2003-06-21T15:41:17-04:00
List-Id: <comp.lang.ada>

tslettebo@chello.no.nospam (=?Windows-1252?Q?Terje_Sletteb=F8?=) wrote 
(abridged):
> It's true that you can't completely leak memory, but you can
> still get the effect of memory leak, resulting from large
> structures still having a reference to them, but which are
> otherwise unused.

Right. You may still need to null out pointers.


> This has also resulted in a host of new kinds of references for
> dealing with it, such as weak, soft and phantom references (in
> Java). Memory leak-like conditions also have expressions like
> lapsed listener, lingerers, laggards and limbo.

These issues also arise even without GC.

Also, GC allows programmers to tackle more ambitious memory
management projects. As the cookie says, "4-wheel drive means
getting stuck in more inaccessible places."


> Garbage collection might make it harder to manage resources, not
> easier.

How? By "resource" you clearly mean "memory" (because you address
non-memory resources below). Without GC we have to decide when to
delete objects. With GC we have to decide when to null pointers.
How can the second question be harder to answer?

(I know there may be issues to do with controlling the collector
itself, but that doesn't seem to be what you are talking about.)

(GC is a big win when objects can be shared by pointers which are
encapsulated. Then the question, "Has everyone finished with this
object?" gets replaced by "Have I finished with this pointer?",
which is a more local, encapsulated issue - fundamentally easier.) 


> Besides, memory is just one kind of resource, and GC does nothing
> for other kinds.

Agreed. You still need to do lifetime management.


> For languages without stack-allocated objects, like Java, you
> can't use RAII in its usual form, either (use of
> constructor/destructor). Instead, you have to resort to
> try-catch-finally, which can lead to spaghetti code, if you
> have several objects to clean up this way.

This would be a criticism of Java, not GC. Most GC languages have
idioms to encapsulate stack-based cleanup. (These are often based
on closures.) RAII is only "usual" in C++.

-- Dave Harris, Nottingham, UK

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]