Garbage collection in C++

[James Kanze]

How would you implement something like a vector without
dynamically allocated memory? I thought dynamically allocated
memory was used because the amount of memory needed can only
be decided at run time.

That's certainly one possible reason. It doesn't affect
application code too often, however, because it's already
handled by things like std::vector. If you're implementing
something like the standard library, my comments probably don't
apply. But I doubt that that's the case for most of us.

I suppose what I don't get is why you would ever want to
create objects on the stack. It's something you can't do in
Java, and it's much quicker to create them on the stack plus
they get destructed automatically when the go out of scope.

I'm not sure I understand what you're saying. You seem to be
contradicting yourself; I suspect that you left out a word
somewhere, but I'm not sure where.

Anyway, unlike Java, C++ has full support for value types, and
you should use them whenever appropriate. In practice, most
objects will be on the stack.

Well, if you are using new in a try block, and an exception is
thrown, C++ will guarantee the destruction of the pointer and
anything else on the stack but it won't call delete for what
you allocated there. I thought the finally block was to "clean
up" any resources you allocated in the try block, something
that isn't necessary if you don't dynamically allocate
resources in there (but instead in the constructors of objects
create there, which are guaranteed to be destroyed).

The finally block is there to do any actions that must be
performed, period. Just because you have garbage collection
doesn't mean that the could be other actions which need to be
performed.

In C++, destructors of on stack objects (RAII) do the same job.
They require a bit more coding to use in isolated cases, but in
general cases (which seem to prevail), they ensure that the
"clean-up" code is implemented with the code which causes it to
be required, and make it much more difficult for the client
programmer to forget it.

 

[James Kanze]

Just because the only place where the memory is deallocated is
inside the destructor, that doesn't mean the memory is
*always* deallocated when the destructor is called. Think
about smart pointers and other similar classes (such as eg.
some implementation of std::string which implements
copy-on-write).

But the only thing forcing the delete into a smart pointer buys
you is confuscation? The main reason for using dynamic memory
at the application level (implementing std::Vector is obviously
a different situation) is because you need arbitrary lifetime.
The object's lifetime ends in response to some external event.
The handler for that event does the delete.

Besides, if the object allocates a variable amount of memory,
then allocation and destruction is obviously necessary
regardless of how you use the object.

If you're talking about things like vector or map, they're
already written, so they're not my problem. If you're talking
about dynamically types objects, it's true that this sometimes
leads to dynamic allocation even if the object logically should
have block scope. I've not found the case to be that frequent,
but it certainly occurs. In such cases, std::auto_ptr is your
friend, and the delete will be called by the destructor of the
std::auto_ptr. Cases where a normal user would write a delete
in a destructor are fairly rare, however (although the
compilation firewall idiom would be an obvious exception).

 

[James Kanze]

In my previous job I worked for over 5 years in an extensive
C++ project, and in my current job I have done so for over 1.5
years. Although counting lines of code is not really a
perfect measurement of the amount of work done, and I haven't
measured exactly how much code I have written in total in
these two jobs, I wouldn't be surprised if it was well over
100k LOC. Many of the programs deal with dynamically allocated
memory in rather complex ways.

I have from time to time checked for memory leaks in all my
programs with profilers. How many memory leaks have I had in
all these years in all my C++ programs? Zero. Not even once
have I had a single memory leak in any of my code. During
these tests I have found many memory leaks in third-party
libraries (which I had to then fix myself), but none in my own
code.

So how is this different from C? Obviously, you can write C++
code which doesn't leak memory. Just as obviously, you can
write C code which doesn't leak memory. It's just a question of
the effort involved.

Also I don't remember even once having accessed freed memory.
I have had a few cases where I have accessed allocated memory
out of boundaries (usually because of an off-by-1 mistake),
but even those have been less than a dozen (mostly in the
earlier years), and caught rather quickly.

The classical C error: strcpy( malloc( strlen( s ) ), s )?
(Back when I was working in C, if someone came to me because
their code was crashing in strange ways, this was the first
thing I'd look for.)

I really haven't ever felt the need for a GC engine in my
work. Could a GC engine have made my job easier in a few
cases? Maybe. I can't say for sure. At most it could have
perhaps saved a bit of writing work, but not increased the
correctness of my code in any way. C++ makes it quite easy to
write safe code when you follow some simple rules.

Yes and no. C++ certainly provides a number of tools which can
be used to improve safety. It doesn't require their use,
however, and I've seen a lot of programmers which don't use them
systematically. And of course, human beings being what they
are, regardless of the tools or the process, mistakes will
occasionally creap in.

 

[James Kanze]

I'll stop right here. The answer is, obviously, "no", insofar
as C++ is concerned.

It's not necessary, no. For that matter, classes aren't
necessary either. Garbage collection is just a tool: it reduces
programmer workload, and increases the security of the resulting
code.

The regular posts here about garbage collection in C++
typically come from newbie programmers who haven't acquired
sufficient discipline to keep track of their own objects.

Yah. Newbies with 20 years of C++ experience. Newbies who
unlike you actually know what they're doing. (FWIW, one of the
proponents of garbage collection in the C++ standards committee
is Bjarne Stroustrup. And he's got even more C++ experience
than I do.)

If I were in your place, I wouldn't talk about newbies. You've
consistently shown a lack of understanding of even the most
basic issues in your own postings.

So they seek for a security blanket called "garbage
collection", so they don't have to worry about it, and can
proceed to churn out their spaghetti code without worry, just
like they do in Java.

That is, of course, the most obvious bullshit I've ever seen.
There are cases where garbage collection isn't appropriate, and
cases where it is necessary. Both are relatively rare; most of
the time, it will save some programmer effort, and result in
cleaner code, but only to a limited degree.

 

[James Kanze]

Sometimes I get the impression that garbage collection
actually causes people to write *less* modular and more
imperative programs. GC doesn't really encourage encapsulation
and modularity.

Garbage collection doesn't "encourage" anything. It's just a
tool. To be used when appropriate. I use it whenever I can,
and find that it results in less lines of code and more robust
and maintainable code.

 

[James Kanze]

although it is not strictly necessary , it has its uses with
concurrent programming it may get really confusing the manage
the lifetime of objects when multiple threads

Attention! Garbage collection does NOT manage the lifetime of
objects. It only manages memory. It's generally useful in
multithreaded environments for performance reasons, but it
doesn't address issues as to which thread has the right to
access which objects when. That problem is completely
orthogonal to how you manage memory (unless you're writing the
memory management code yourself, of course).

 

[James Kanze]

So is a shovel. It's also a tool. There are situations where
you can use a shovel to do something useful. C++ isn't one of
them.

You might try a better analogy. Shovels aren't used in
programming in general (although there are more than a few
programs that I would like to bury). Garbage collection is
useful in C++, and in fact, is actively being used by a number
of programmers.

Don't get snippy with me, young man. I outrank you by a few
years.

If you did, you'd be retired. (The first machine I ever
programmed was an IBM 1401. Beat that if you can.)

A quick search finds no evidence that he is a "proponent" of
garbage collection.

Have you checked in the discussions on the mail reflectors of
the standardization group? He's more interested in other
aspects, but has expressed himself in favor of garbage
collection on several occasions.

Note that this is an evolution in his position (due, I suspect,
to an evolution in garbage collection technolgy); before 1990,
he doubtlessly could have added it without really asking anyone.
But the technology available before 1990 is a far cry from what
is available today.

He discusses the subject, but not from a position of advocacy,
and actually argues that there are better techniques
available, in C++, than garbage collection.

There are certainly better techniques for some things. For
others, not necessarily. Anything which reduces the amount of
code I have to write myself is a good thing; there are enough
real problems in my applications that I don't have to
artificially create extra work just to keep me busy. And like
all techniques, it can easily be abused, but the fact that
something can be abused isn't a reason for not including it in
C++.

The only real problem garbage collection has is that it has been
presented as a panacea by some (not all) Java proponents; I've
actually been told that you couldn't have memory leaks in Java,
because of garbage collection (at the same time that Sun was
admitting to serious memory leaks in Swing). If you expect
garbage collection to solve every problem, you're going to be
disappointed. But that's not a problem with garbage collection;
that's a problem with your expectations. (And it's not really
unlike many of the postings here on the subject of smart
pointers.)

 

[Chris M. Thomasson]

That is, of course, the most obvious bullshit I've ever seen.
There are cases where garbage collection isn't appropriate, and
cases where it is necessary.

Humm.. Can you give an example or two of a scenario in which a GC is
absolutely required/necessary? For some reason, I can't seem to think of one
off the top of my head. What am I missing? Perhaps I misunderstand your use
of the word "necessary"...

Both are relatively rare; most of
the time, it will save some programmer effort, and result in
cleaner code, but only to a limited degree.

I have seen a couple of cases in which a GC covered up more than a "simple
memory leak". Simple example... What if the memory leak was entangled in a
logic error that sometimes caused weird execution results. If the programmer
was alerted to the memory leak, perhaps he/she could have noticed the logic
error as well. Of course, this is highly contrived case. However, it can
occur.

One bad thing about GC is that it sometimes pulls programmers into a false
sense of security, and they end up creating a sloppy design. This is NOT the
fault of the GC, but of the lazy programmer. One can create efficiently
engineered programs _and_ use a GC at the same time.

 

[Juha Nieminen]

So how is this different from C?

C++ makes it much easier to write safe code, and following the
principles which make code safer is much simpler. In other words, there
are lots of situations where you simply don't have to worry about
leakages in any way in C++, while you do have to worry about then in C
because C doesn't help automatizing.

For example, if I instantiate an std::istream at the beginning of a
function, I just don't have to care about closing that file handle at
all. The std::istream object does it automatically for me completely
regardless of where, when and how the function in question is exited,
and regardless of how many exit points it might have. This is not the
case in C, where you always have to be very careful to not to leak (a
file handle in this case).

A garbage collection engine would certainly be much more useful when
programming in C because in C it requires a lot more work to write safe
code, and a GC engine can help a lot in that. In C++ it's my personal
feeling that a GC engine is not *that* useful.

(Of course regardless of having a GC, you can still leak file handles.)

 

[Juha Nieminen]

Garbage collection doesn't "encourage" anything.

I tend to disagree. Garbage collection encourages writing
"irresponsible" code. By this I mean that since there's no need for
objects to have (memory handling) responsibilities, it easily leads to
the programmer not creating such objects at all, which in turn leads to
a more imperative style of programming, rather than a more modular style.

Some people may (and do) argue that this is a good thing, but I
wouldn't be so sure. Granted, you won't leak memory (well, not
permanently at least), but your code may suffer from spaghettification
just because you were too lazy to actually write some modules rather
than writing "raw" code.

And no, this doesn't mean *all* programmers using a GC'd language
suffer from this.

It's just a tool. To be used when appropriate.

Well, if it would be a *choice*, then it wouldn't be so bad. There are
languages, however, where you are force-fed and you have no choice.

 

[Chris M. Thomasson]

C++ makes it much easier to write safe code, and following the
principles which make code safer is much simpler. In other words, there
are lots of situations where you simply don't have to worry about
leakages in any way in C++, while you do have to worry about then in C
because C doesn't help automatizing.

For example, if I instantiate an std::istream at the beginning of a
function, I just don't have to care about closing that file handle at
all. The std::istream object does it automatically for me completely
regardless of where, when and how the function in question is exited,
and regardless of how many exit points it might have. This is not the
case in C, where you always have to be very careful to not to leak (a
file handle in this case).

Closing a file handle in a dtor can be _very_ problematic indeed; read here:

http://groups.google.com/group/comp.lang.c++/browse_frm/thread/ec97ab562016d016

 

[Chris M. Thomasson]

Closing a file handle in a dtor can be _very_ problematic indeed; read
here:

http://groups.google.com/group/comp.lang.c++/browse_frm/thread/ec97ab562016d016

[...]

refer to the file copy problem in following post:

http://groups.google.com/group/comp.lang.c++/msg/78a928139ca349f4

if the system specific internal call to close the file fails in the dtor of
the higher level file object, well, then the shi% will hit the fan;
permanent data loss! Ouch.

:^/

 

[Hans Bos]

I tend to disagree. Garbage collection encourages writing
"irresponsible" code. By this I mean that since there's no need for
objects to have (memory handling) responsibilities, it easily leads to
the programmer not creating such objects at all, which in turn leads to
a more imperative style of programming, rather than a more modular style.

Are saying that people that can't make proper programs using garbage
collection will make good programs without gc?

 

[Keith H Duggar]

Yes and no. C++ certainly provides a number of tools which can
be used to improve safety. It doesn't require their use,
however, and I've seen a lot of programmers which don't use them
systematically. And of course, human beings being what they
are, regardless of the tools or the process, mistakes will
occasionally creap in.

Yes. However, garbage collection is /only/ going to reclaim
memory, eventually. It's not going to correct the logical and
potentially far more serious design bugs that leaked memory
in the first place. In fact, garbage collection can and does
hide bugs exactly by allowing access to objects that should
not be accessed thus actually reducing correctness. How do
you respond to this?

The various C++ techniques that of course are familiar to you
for managing memory deterministically not only help one prevent
garbage memory, they also help one properly manage other scare
resources which garbage collection does nothing for. How do you
respond to this? Is it not better to learn the more general more
comprehensive deterministic resource management paradigms that C++
supports? And to apply them uniformly and widely?

C++ is a multi-paradigm language, usable in many contexts. If
you're writing kernel code, a garbage collector certainly has
no place; nor do exceptions, for that matter. And if you're
implementing a garbage collector, obviously, you can't use it.
But for most application programs, it's stupid not to.

RAII, RRID, STL containers, automatic variables, value types,
and other software design patterns have served exceptionally
well in eliminating both the need and the want for GC for me.

Furthermore almost every memory management problem I remember
finding recently that would have gone unnoticed with GC in use,
was not only a resource management problem but was also a flaw
in logic or design that was much better found than swept under
the GC rug.

Finally, the deterministic design patterns C++ supports for
memory management also apply directly to other scare resources
such as ports, handles, connections, locks, etc. The same cannot
be said for GC.

In light of the above, why is it "stupid" not to use GC?

KHD

 

[Keith H Duggar]

Attention! Garbage collection does NOT manage the lifetime of
objects. It only manages memory.

Attention! In practice the above is FALSE! If it were correct
there would not have been the rather lengthy discussion recently
in comp.lang.c++.moderated among a few of the world's foremost
C++ experts regarding "zombie" states etc.

http://groups.google.com/group/comp.lang.c++.moderated/browse_frm/thread/c9079ef911de670f/

(Don't be fooled by the topic. It was a Trojan Horse bearing the
gift of GC. For example see the subthread starting with post 63.
If the link fails search for "throwing default constructors".)

When one tries to divorce, in practical terms, the concepts of
object "lifetime" and object "storage" the can opens and spills
worms all over your language model. Since you did not post in
that recent thread I'm not sure what your solution for

"destroyed but not deallocated"

is. If you have one please post it so that Andrei and the like
can employ (or at least research) it.

KHD

 

[James Kanze]

James Kanze wrote:

[...]

A garbage collection engine would certainly be much more
useful when programming in C because in C it requires a lot
more work to write safe code, and a GC engine can help a lot
in that. In C++ it's my personal feeling that a GC engine is
not *that* useful.

For what definition of "that". It's certainly not as essential
as it is in Java. On the other hand, it fits into the
philosophy of C++, giving the programmer a maximum of tools for
him to choose from, rather than a limited set, predefined by
someone's idea of what is "good".

(Of course regardless of having a GC, you can still leak file
handles.)

That's an entirely different issue, which neither GC nor RAII
really address; unlike freeing memory, freeing a file handle can
fail, so you have to do it explicitly, in order to check the
status and handle a possible error. (It's also different
because it affects state outside the program; until you close
the file, other programs can't see what you've written to it.)

 

[James Kanze]

Yes. However, garbage collection is /only/ going to reclaim
memory, eventually. It's not going to correct the logical and
potentially far more serious design bugs that leaked memory in
the first place.

Woah. If the error is leaked memory, garbage collection may
correct it. Or it may not, depending on whether there is still
a pointer floating around to the memory. (The Java bugs data
base has more than a few cases of memory leaks in it.)

That's not what garbage collection is for. Garbage collection
isn't designed to make an incorrect program correct---I don't
think any tool can guarantee that. Garbage collection (like all
of the other tools I know) is designed to make it easier to
write a correct program. It also makes the effects of some
errors (dangling pointers) less critical.

In fact, garbage collection can and does hide bugs exactly by
allowing access to objects that should not be accessed thus
actually reducing correctness. How do you respond to this?

How should I respond to some wild and erroneous claim? In fact,
garbage collection helps to detect bugs; it is necessary in
order to effectively detect precisely the bug you describe.
Without garbage collection, it's undefined behavior; with
garbagea collection, it's a testable condition.

The various C++ techniques that of course are familiar to you
for managing memory deterministically not only help one
prevent garbage memory,

They also require additional work.

they also help one properly manage other scare resources which
garbage collection does nothing for. How do you respond to
this?

Different "resources" have different constraints. Garbage
collection is fine for memory. RAII often (usually?) works well
for locks and such. You need explicit, programmer controlled
management for resources such as open files, where "release" can
fail. One size doesn't fit all.

Memory is, of course, a very special resource, since it is used
by *all* objects. Only a very small subset of objects use any
other resource (except CPU, but that one pretty much takes care
of itself). So if memory is automatically managed, only a very
small subset of objects need explicit handling, rather than all
of them. Which means less work for the programmer.

Is it not better to learn the more general more comprehensive
deterministic resource management paradigms that C++ supports?
And to apply them uniformly and widely?

You need to understand many different types of resource
management (and often transaction management in general---the
problem isn't just resources) if you want to write correct code.
Garbage collection doesn't dumb down the language, so that
idiots can use it. It just means that an intelligent programmer
has less lines of code to write. No more, no less.

RAII, RRID, STL containers, automatic variables, value types,
and other software design patterns have served exceptionally
well in eliminating both the need and the want for GC for me.

Exactly. You've mentionned a number of very useful tools.
Garbage collection is just one more to add to the list.
Sometimes, it will mean that you need to write less code.

Furthermore almost every memory management problem I remember
finding recently that would have gone unnoticed with GC in
use, was not only a resource management problem but was also a
flaw in logic or design that was much better found than swept
under the GC rug.

That's an oxymoron. If it was a memory management problem, then
garbage collection might have solved it (or it might not---if
you leave unused entries in an std::map, garbage collection
isn't going to remove them for you). If it was a flaw in logic
or design, then it's not a memory management problem. And if it
isn't detected by your development process (code review, tests,
etc.), with or without garbage collection, then you have a
serious problem in your development process.

Finally, the deterministic design patterns C++ supports for
memory management also apply directly to other scare resources
such as ports, handles, connections, locks, etc. The same
cannot be said for GC.

Except that there is no one design pattern that applies equally
to all resources (or other state which must be rolled back).

In light of the above, why is it "stupid" not to use GC?

Not doing so means more lines of code. If you don't have enough
to do, and your employer is happy to pay you for busy work,
fine. Otherwise, you really should have garbage collection in
your tool kit (supposing other constraints allow it).

 

[James Kanze]

I tend to disagree.

Sorry, but it's a statement of fact. Garbage collection is just
a tool; a piece of code. It can't encourage or discourage
anything.

At one time, some proponents of garbage collection were trying
to sell it as a silver bullet. Or rather, to sell it as part of
a larger package which was presented as a silver bullet.
Serious programmers, of course, no that silver bullets don't
exist.

Garbage collection encourages writing "irresponsible" code.

How can some code in your machine encourage anything. You're
attributing motives and characterists of a living being to an
inanimate object. (There's a name for this, but I've forgotten
it. But it's frequent among programmers---how often do you hear
a programmer talk about a "bug" which "crept into" his software,
rather than to say "I made an error"?)

By this I mean that since there's no need for objects to have
(memory handling) responsibilities, it easily leads to the
programmer not creating such objects at all, which in turn
leads to a more imperative style of programming, rather than a
more modular style.

Sorry, but I can't follow this at all. Garbage collection
certainly reduces the need for objects dedicated uniquely to
memory management, but how does this relate to whether code is
imperative or not.

For that matter, there are cases where an imperative style is
good. One size doesn't fit all; you need to use the appropriate
technique, among all of those available, to solve each problem.
In practice, garbage collection makes OO (OO in the sense of
using polymorphic objects) easier; polymorphic objects generally
have to be allocated dynamically (supposing the exact type not
known at compile time).

Some people may (and do) argue that this is a good thing,

What is a good thing?

but
I wouldn't be so sure. Granted, you won't leak memory (well,
not permanently at least),

Where to you get this. Garbage collection doesn't mean that you
won't leak memory. The bug list for Java contains a number of
memory leaks.

but your code may suffer from spaghettification just because
you were too lazy to actually write some modules rather than
writing "raw" code.

And no, this doesn't mean *all* programmers using a GC'd
language suffer from this.

Programmers who want to write spaghetti will write spaghetti.
With or without garbage collection. You're not going to claim
that C and C++ encourage readability, I hope. Not with the
preprocessor, pointer arithmetic, and their declaration syntax.

Well, if it would be a *choice*, then it wouldn't be so bad.
There are languages, however, where you are force-fed and you
have no choice.

We're talking about C++ here. Where the guiding principle is
that the programmer knows best. And the philosophy is to give
him as many different tools as possible, for him to choose what
it best at any given time.

Other languages have other philosophies. In some cases, what
they were trying to force-feed you wasn't actually a bad idea.
(I'm thinking of Eiffel and programming by contract.) But even
then, experience (mine, anyway) shows that it doesn't pay off in
the long run. As the technology (the tools set) becomes more
widely used, we learn more about it, and change our ideas
somewhat about how to use it.

There are doubtlessly applications where garbage collection
shouldn't be used at all. (There are, in fact, applications
where dynamic memory shouldn't be used at all.) And it
certainly isn't the solution for everything. But the fact that
a technology can be misused has never been an argument against
introducing it into C++, provided that it also has advantages
when correctly used.

 

[James Kanze]

No, they won't make any programs at all.

Which is a good thing. But only from a theoretical viewpoint.
From a practical viewpoint, those kinds of people should be
encourage to spew out reams of atrocious code. Some people
make a pretty good living cleaning up these messes.

. Yes. For a long time, C was my job security. Nothing
quite beats pointer arithmetic for spewing out reams of code
that only a guru can maintain, and the implicit declaration of
functions can be pretty cool too.

I'll admit that I don't quite understand this argument with
regards to garbage collection. Bad programmers will be bad
programmers, with or without garbage collection. ("The
determined Real Programmer can write Fortran in any language.")
C++ already offers a lot of useful features for making a mess of
things; globally, I think that in the hands of a good
programmer, garbage collection will result in smaller, easier to
understand programs (that corresponds to my experience, at
least---and I consider myself a good programmer), but I'm sure
that the bad programmers will find original ways to use it to
screw things up as well.

This is, I think, a major point in the philosophy of C++. Some
languages try to limit you to a small subset of programming
constructs, claiming that doing this will ensure maintainable
programs (or sometimes even claiming that it will ensure correct
programs). Of course, each new language in this group disagrees
which constructs, and it never works out in the end---bad
programmers are too clever. C++, on the other hand, takes the
attitude that the programmer is a mature and responsible adult,
and is not totally incompetent. And that you can and should
give him whatever tools he can best make use of, even if he
could abuse them. Or to use a frequent analogy, some languages
won't give you a saw, because you might cut yourself. C++ gives
you a chain saw, a rip saw, a band saw, and a couple of other
types of saws. So you can cut yourself badly if you don't know
what you're doing. But also cut wood, metal, or anything else,
in just about any shape you want. In this regard, garbage
collection is just another type of saw.

 

[James Kanze]

Garbage collection is as useful for C++ as a fifth leg would
be useful to a dog. A dog with five legs might find some use
for the extra one, but most of the time it would just get in
the way.

Another ridiculous analogy, which doesn't relate to anything.

Some people may find some cockamamie "garbage collection
library" useful, but many more do not.

Really. Every one I've talked to who's used the Boehm collector
has found it useful.

Furthermore, there are also people who also find intermediate
code generators useful too. Specifically ones that swallow
some glob of XML, and spew out robo-generate spaghetti code
that does something else XML-related. It's useful to a small
minority, because it allows them to put their brain in "park",
and not bother learning how the stuff should work. Which
leaves them completely helpless if the end result does not
work as expected, since they have no clue how the spaghetti
code works, and what's wrong with it.

In other words, if I need to tokenize input, I should write my
tokenizer by hand, rather than use some regular expression based
tool. If I want to test my application, I should write all of
the boiler plate code by hand, rather than using some test
generator. If I want to run a program consisting of machine
instructions, I should write the machine instructions by hand,
rather than using some compiler and linker.

I think you're being a bit silly. And missing the point. Doing
less work (writing less lines of code, etc.) is good.

There is no such magic wand that one can wave, and make a
bunch of code disappear. Anyone who thinks that is fooling
themselves. Garbage collection-based design results in larger
memory requirements, greater resources, and slower code.

Than what? In the cases I've actually seen, garbage collection
does result in increased memory use, sometimes significantly,
and this must be taken into account. (But what is cheaper,
memory, or programmer time.) In most cases, it results in the
program running faster, or appearing to. (But of course, you
could manually optimize the non-garbage collected code to do the
same thing.)