home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: comp.lang.c++
- Path: sparky!uunet!microsoft!hexnut!jimad
- From: jimad@microsoft.com (Jim Adcock)
- Subject: Re: Garbage Collection for C++
- Message-ID: <1992Aug18.011336.17964@microsoft.com>
- Date: 18 Aug 92 01:13:36 GMT
- Organization: Microsoft Corporation
- References: <DAVEG.92Aug13025629@synaptx.synaptics.com> <TMB.92Aug14130323@arolla.idiap.ch> <1992Aug15.025613.4571@news.mentorg.com>
- Lines: 21
-
- In article <1992Aug15.025613.4571@news.mentorg.com> bcannard@hppcb36.mentorg.com (Bob Cannard @ PCB x5565) writes:
- |There are plenty of reasons whey GC is genuinely more efficient than
- |manual: it allows better-designed data structures, it eliminates the need to
- |copy data which plagues large systems using manual recycling, and it reduces
- |development and maintenance costs. But the idea that GC is inherently faster
- |than manual is bogus.
-
- Likewise the idea that manual is inherently faster than GC is bogus. Likewise
- the idea that any memory management scheme is inherently faster than some
- other memory management scheme is bogus. Its always possible to come up
- with examples where one memory management scheme excels and the other
- memory management technique stinks. Taken to the extreme, one creates an
- example where one memory management scheme works, and the other technique
- fails, thus "proving" the superiority of one's pet memory management scheme.
- No memory management scheme wins uniformly. But, if one must constantly write
- custom allocators, then one has destroyed code reuse. An example of this is
- the problem of "dueling global news" or "dueling multiple inheritence news"
-
- GC'ed vs non-GC are two major poles of memory management. Both have advantages,
- both should be supported, unfortunately they cannot be cleanly mixed.
-
-