Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Garbage Collection - The Trash Begins To Pile Up

35 views
Skip to first unread message

Le Chaud Lapin

unread,
Dec 27, 2006, 4:56:05ā€ÆAM12/27/06
to
The purpose of this post is to provide a bit of empirical evidence that
GC is no panacea, and that adding it to C++ might do more harm than
good.

A while ago, I initiated a thread in comp.lang.c++.moderated called
"Garbage Collection - Stop Making Trash!". In that thread, some of us
argued, yet again, that adding garbage collection to C++ would
seriously degrade the integrity of the language. For GC proponents,
our arguments were insufficient, especially those who had deep
experiences with/vested interest in languages like C++/CLI and C#.
Some of these people also failed to see anything wrong with referring
to C++/CLI as "Pure C++" though that has finally been rectified by
renaming the "Pure C++" column, "Netting C++"
http://msdn.microsoft.com/msdnmag/issues/06/08/nettingc/default.aspx

What I have noticed over the past 6 months is something peculiar that
one would never expect from the world of GC. Every article related to
.NET or C# that I have seen has had to do with

1. memory management
2. resource cleanup.

For example, the web start page of the Visual Studio 2005 IDE formerly
linked here:

http://msdn.microsoft.com/msdnmag/issues/06/08/nettingc/default.aspx

The beginning of this article states:

"A garbage-collected heap has deep ramifications for destructors, and
that's where we'll start."

"Deep ramifications." That's strange. I thought the purpose of GC was
to relieve the programmer of thinking about deep ramifications.

There have been numerous such articles popping up over the past 6
months. I saw four in the same afternoon two weeks ago. One colleague
had a memory management issue that had something to do with an object
not going away when he wanted it to and asked me to help. As my GC
experience is limited to Lisp, I could not, but I vaguely remember
arriving at the conclusion based on his description of C#'s memory
management model that there was nothing he could do - he was at the
mercy of the GC. Another colleague of mine who abandoned C++ in favor
C# for a year finally came back to the land of deliberate form and
declared, "...well...I still like C# for GUI development, but you get
what you pay for. You have to architect your code right no matter
which language you use. Garbage collection simply makes it more
difficult to find where bad code is being bad."

Another example is the current Visual Studio 2005 IDE start page:

http://msdn.microsoft.com/msdnmag/issues/06/11/CLRInsideOut/default.aspx

"Uncovering and correcting memory issues in managed applications can be
difficult. "

That sentence says it all. This is written written by a company that
had full control over the garbage collection system of a language it
created. Unlike C++, they had absolute control over the the memory
management system to mold it as they saw fit. Yet, when a programmer
uses the GC model, they might experience the following problems:

* An OutOfMemoryException is thrown.
* The process is using too much memory for no obvious reason that
you can determine.
* It appears that garbage collection is not cleaning up objects
fast enough.
* The managed heap is overly fragmented.
* The application is excessively using the CPU.

All of these symptoms make me wary, but the second (*) is most
impressive... "for no obvious reason that you can determine". The
last word in this sentence, "determine", is closely related to another
word, "determinism", a feature of C++ that is probably the basis for
having never experienced any of these problems in C++.

-Le Chaud Lapin-


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

lance...@nyc.rr.com

unread,
Dec 27, 2006, 12:19:04ā€ÆPM12/27/06
to

Le Chaud Lapin wrote:
> The purpose of this post is to provide a bit of empirical evidence that
> GC is no panacea, and that adding it to C++ might do more harm than
> good.
Most of the problem is that 'Automatic GC" always seems to imply
this feature -- the collected trash is always free store memory that
may have cyclic references or pointers.
However, but time and time again we rediscover that cyclic object
references always imply that you cannot have deterministic destructors,
because cycles themselves cannot be reclaimed deterministically, but
must wait for a "cycle detecting agent."
And we all know by now that the vast majority of resources must be
handled in a deterministic fashion. Imagine not freeing file or socket
handles, until you've exhausted the system - this is the strategy
that "Automatic GC" takes with your memory.

The truth of the matter is that C++ DOES have automatic garbage
collection. The difference is that the C++ version uses a stack based
semantic - it takes out the trash in the same way that your call
stack has done for 40 some years. (Ironically, back then Stack based GC
was the center of controversy. Go figure.)

So if you really don't need
1 . cycles of pointers, and the cases where you do want this are very
well understood, and there are now standard ways of dealing with it,
and,
2. you are careful about the life of references passed as return values
(something "Automatic GC" does solve)
then C++ coupled with RAII is a far superior solution to the strategy
Java / C# uses.

So just what is the point of adding the feature that we don't have to
worry about heap memory cycles and disappearing references every so
often, but now we have to manually manage every other resource, worry
about zombie objects (disposed but still alive otherwise) and worry
about processes using 2GIGs of memory because the GC engine wasn't
manually invoked after all???

The only reason I can see for trying to stuff Cyclic Heap Memory GC
into C++ Stack based model is for integration with platforms that use
these style heap management, i.e.
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1956.pdf But
even here there is no real reason you could not just override operators
new / delete to use the systems heap in the traditional way.
Who needs the "Dispose" pattern when you have destructors???

Stephen Howe

unread,
Dec 27, 2006, 12:15:40ā€ÆPM12/27/06
to
> A while ago, I initiated a thread in comp.lang.c++.moderated called
> "Garbage Collection - Stop Making Trash!". In that thread, some of us
> argued, yet again, that adding garbage collection to C++ would
> seriously degrade the integrity of the language. For GC proponents,
> our arguments were insufficient, especially those who had deep
> experiences with/vested interest in languages like C++/CLI and C#.
> Some of these people also failed to see anything wrong with referring
> to C++/CLI as "Pure C++" though that has finally been rectified by
> renaming the "Pure C++" column, "Netting C++"
> http://msdn.microsoft.com/msdnmag/issues/06/08/nettingc/default.aspx

Your post is interesting, particularly the articles of what happening in the
..NET world concerning memory management and RC. And I agree with you on the
damage of adding GC to C++. But I regard it as alarmist, the addition of GC
to C++ will _never_ happen except as an optional component which was
Bjarne's original vision (and to date in tihs newsgroup, I have never seen a
GC aficionado talk about the optionality of GC for C++ which leads me to
believe they regard it as compulsory). Optional I can live with. At this
point it becomes political in whether the "option" is purely by the
programmer as well as the vendor.

Cheers

Stephen Howe

bruno_pages

unread,
Dec 27, 2006, 12:32:34ā€ÆPM12/27/06
to
My 'deep' experiences with the garbage collectors was also made with
Lisp many years ago. At this time I work on a project named MAIA whose
include the implementation of Common Lisp. One year before starting
with this project, in fact during my DEA (Bac + 5 study in France) I
write a small Lisp on Goupil, and obviously I implemented a GC : the
mark & sweep.

As I know there are several ways to implement a GC :
- the mark & sweep : when there is no available memory block for an
allocation, the still reached memory blocks are search in the memory,
registers and stack. The non reached memory is collected to be placed
in the heap. The reached memory is unchanged. As you can understand
this create hole in the memory when the allocated block have different
sizes. Obviously during the GC the application is stopped.
- the stop and copy : the memory is divided by two, at a given moment
only one half is used. When there is no available memory block for an
allocation, the still reached memory blocks are search in the memory,
registers and stack and moved from the current half memory to the other
one. The disavantage is to divide the memory by two, but after each GC
there is no hole in the memory because the still used memory blocks are
packed. Obviously during the GC the application is stopped.
- the incremental stop & copy : this GC use the assumption "generally
an allocated object become unused very soon or has a long life". This
GC is an extension of the stop & copy, the memory is not divided by two
but by several couples of memory area. Let's suppose there are two
couples of memory areas, one couple (S1-S2) is very small compared to
the other one (L1-L2), the allocation are always made in the small area
which 'turn' very quickly, when a GC occurs the still reached memory
blocks whose resist still the previous GC goes in the large memory
area. So the blocks having a short life don't go in the large area, and
because the small are is small the GC is fast. An other advantage is
that the large area is managed incrementally during the execution, the
goal is to not top brutaly the execution. The implementation of this GC
is very complicated, it was used with success for MAIA, but to work the
GC must be taken into account in many levels, even in the OS.
- the counters : each allocated block has a counter of reference, when
the counter become 0 the block is free for a re-use. Like for the mark
& sweep the blocks are never moved, so some hole appears, furthermore
some objects are never free, for instance when you have a circle each
element is still referenced even the circle itself is not referenced.
The advantage of this GC is that the execution is never stopped (...
except if you add an other GC to manage circle), but you must update
the counter of references each time an address is saved 'somewhere'.

I don't know which GC is used by Java, I just can see that during the
GC the execution is stopped. More that the cost of the GC itself, the
disavantage is that when a GC is present all the allocations are made
in the heap, and an allocation / desallocation in the heap is
expensive. In C++ temporary allocations may be made in the stack, in
this case and the 'allocation / de allocation' cost is nothing, it is
enough to update the stack pointer :-)

To have or not a GC can't be considered out of any external reasons,
all depend on the usage of the language. For instance to have a GC in
Java and to pay for that is not a problem in many cases where the
respons time is not a problem, and where you don't want to 'loose'
implementation time to save the memory, for instance to execute a small
program attached to a web feature. The problem is not the GC in Java,
the problem is to use Java in the cases it is not adapted and for
instance where C++ is a better choice ... Each language has its
advantages, but the more the language is specific, the less its field
of application is large.

Bruno

Bruno

Francis Glassborow

unread,
Dec 27, 2006, 3:49:20ā€ÆPM12/27/06
to
In article <1167208673....@h40g2000cwb.googlegroups.com>, Le
Chaud Lapin <jaibu...@gmail.com> writes

>"Deep ramifications." That's strange. I thought the purpose of GC was
>to relieve the programmer of thinking about deep ramifications.


But GC is about memory management which is a subset of destructors that
are about resource management.

There are many places in modern program design where we would love to
avoid having to worry about memory management and GC does that for us.
Unfortunately in many languages that rely on GC, the result is that the
programmer has to explicitly manage all other resources and so be aware
of the lifetimes of all objects that use dynamic resources (other than
memory). Those resources are often far scarcer than memory yet few
objects rely on them The consequence is that programmers are more likely
to mismanage them (things that rarely matter are much harder to learn)

Our problem in C++ is to couple GC and dtors to provide an optimal mix,
memory is managed implicitly and other dynamic resources are managed by
dtors. The problem is not for the programmer but for the language
design. If we can get it right we have a win-win situation (and those
who do not want to use GC, need not do so.)

The intent is NOT to force everyone to use GC, but to ensure that those
using it can still rely on dtors for other resource management. We very
definitely do not want to loose the latter capability in providing the
former.

I get pretty irritated by people who continually oppose something on the
grounds that they have no use for it. By all means oppose something if
the consequence is detrimental to something you do use.

Yes there are issues of overall complexity and the Standards committees
are pretty sensitive to those. However GC has always been considered as
an optional tool in C++ (certainly Bjarne Stroustrup has never been
against it as such, only against making its use compulsory)


--
Francis Glassborow ACCU
Author of 'You Can Do It!' and "You Can Program in C++"
see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects

Francis Glassborow

unread,
Dec 27, 2006, 3:48:56ā€ÆPM12/27/06
to
In article <Df-dndbRhfBH7w_Y...@pipex.net>, Stephen Howe
<sjhoweATdialD...@giganews.com> writes

>But I regard it as alarmist, the addition of GC
>to C++ will _never_ happen except as an optional component which was
>Bjarne's original vision (and to date in tihs newsgroup, I have never seen a
>GC aficionado talk about the optionality of GC for C++ which leads me to
>believe they regard it as compulsory).

I have never seen one write as if he thought it should be compulsory. I
have several time posted asserting the optional nature and I have never
had anyone post to rebut that as being insufficient for their needs.

I am pretty certain that none of them regard it as compulsory other than
that it should be required that implementations support GC (not that
does not mean anyone has to use it :)

--
Francis Glassborow ACCU
Author of 'You Can Do It!' and "You Can Program in C++"
see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects

Greg Herlihy

unread,
Dec 27, 2006, 3:57:35ā€ÆPM12/27/06
to
Le Chaud Lapin wrote:
> Yet, when a programmer
> uses the GC model, they might experience the following problems:
>
> * An OutOfMemoryException is thrown.
> * The process is using too much memory for no obvious reason that
> you can determine.
> * It appears that garbage collection is not cleaning up objects
> fast enough.
> * The managed heap is overly fragmented.
> * The application is excessively using the CPU.
>
> All of these symptoms make me wary, but the second (*) is most
> impressive... "for no obvious reason that you can determine". The
> last word in this sentence, "determine", is closely related to another
> word, "determinism", a feature of C++ that is probably the basis for
> having never experienced any of these problems in C++.

In comparison, the typical memory problems of a C++ program are far
more serious: memory leaks, heap corruption, memory "stomping", invalid
output, "crashes" far removed from the site of the error - the variety
of potential C++ memory-management errors is practically infinite, and
uniformly disasterous.

Unless C++ is intended to become a programming language exclusively for
hobbyists and others who write programs for their own enjoyment - then
the C++ language has to evolve from its 80s-era origins if it is to
remain economically competitive as a programming language today.
Fortunately, the C++ committee can read the writing on the wall as well
as anyone: manual memory management is far too error-prone, produces
programs that are far too expensive to debug and maintain, and even
fails to deliver on the type safety guarantees of the language itself,
to be presented as a serious alternative to automated memory
management.

C++ without any form of automated memory management cannot be taken
seriously as a commercial-grade computer programming language today,
and even less so, tomorrow.

Greg

Le Chaud Lapin

unread,
Dec 27, 2006, 11:38:13ā€ÆPM12/27/06
to
Francis Glassborow wrote:
> I am pretty certain that none of them regard it as compulsory other than
> that it should be required that implementations support GC (not that
> does not mean anyone has to use it :)

But Francis,

Don't you think that this will cause a lot of confusion about how to
best handle memory management? What about the the reputation of the
language?

If GC is added to the language proper:

1. Advanced C++ programmers who never wanted GC in C++ will already
know to abstain from using it as the general mechanism for memory
management.

2. Advanced C++ programmers who wanted GC in C++...I have no idea what
they would do... but I suspect that a significant number of them will
use it as the general mechanism for memory management for x% of the
time, where x is a number > 1 and < 100. Because we are all human,
dx/dt will likely be > 0.

3. Novice C++ users will likely lack the experience to properly judge,
and being an educator, certainly you would agree that beginners often
choose the path that they perceive to be that of least resistance.
That's why GC is so popular in C# and Java - there is the common
misconception that it relieves them from having to think about memory
management. The same happens in other disciplines.

But the vast majority of programmers do not program in isolation. Code
is written, shared, maintained, passed along, prescribed, etc.
Eventually, novice become experts, if not by skill, then by title.
Then you end up with a situation where people who were once novices are
prescribing designs that are inherently flawed because of the erroneous
perception that memory does not have to be managed. Their lack of
forethought in the design adversely affects the quality of the code.
The poor code quality leads to instability, unreliability, and
significant problems with maintainability. And this ultimately affects
the reputation of C++.

In the technical press, no one will write, "Engineers not appreciating
the fundamental principle of good form falsely assumed that GC was a
silver bullet and repeatedly concocted designs that were inherently
defective, unwieldy, unstable, and unreliable using a language that
readily supports good form, stability, and reliability: C++."

Instead they will write, "C++ has serious memory management issues."

After that, we anti-CG programmers could quickly find ourselves in a
situation defending C++ against managerial revocation due to a
degradation in integrity that was, ironically, induced by people who
never understood the spirit of the language in the first place. This
is a real possibility - just recently, the boss of a friend of mine in
a software company declared that there would be a complete rewrite of
all the code - in C#. The problem was COM ...someone got the idea 10
years earlier that COM was the solution to all things grand - and it
turned out that it was not, and the (wishfully-thinking) programmers
made a horrific mess out of the code base, but C++ got a bad reputation
for it. Now my friend could try to say to his boss - "Wait...the
problem wasn't C++...the problem was that you used C++ in a manner that
counter to its proper usage."..but that won't matter. What is done is
done. C++ is out. C# is in.

So I would rethink the notion that adding GC to the language is
harmless because the use of it is optional. If that were the case,
then we might as well add support for inline Lisp and many other things
that an equal number of people would consider useful.

-Le Chaud Lapin-


--

Nemanja Trifunovic

unread,
Dec 27, 2006, 11:36:18ā€ÆPM12/27/06
to

Le Chaud Lapin wrote:
> The purpose of this post is to provide a bit of empirical evidence that
> GC is no panacea, and that adding it to C++ might do more harm than
> good.

I agree with most of the points from your post, but there is nothing to
worry about: C++ is not and will *never* be a garbage-collected
language. It is possible that we see optional garbage collection added
to the language, but I doubt even that will happen.

Le Chaud Lapin

unread,
Dec 27, 2006, 11:39:43ā€ÆPM12/27/06
to
Greg Herlihy wrote:
> In comparison, the typical memory problems of a C++ program are far
> more serious: memory leaks, heap corruption, memory "stomping", invalid
> output, "crashes" far removed from the site of the error - the variety
> of potential C++ memory-management errors is practically infinite, and
> uniformly disasterous.

This viewpoint is very old in engineering and simply wrong. I've had
computer science students complain that electrical engineering would be
more fun if the math were not so complicated.

The problems you listed are caused by programmers doing things they
should not be doing. The degree to which such problems manifest is
directly proportional to the degree to which programmers persists in
doing things that they should not be doing.

> Unless C++ is intended to become a programming language exclusively for
> hobbyists and others who write programs for their own enjoyment - then
> the C++ language has to evolve from its 80s-era origins if it is to
> remain economically competitive as a programming language today.

The only group I see clearly benefiting from the "evolution" of C++ is
a large software company in the northeastern United States. The mess
caused by introducing GC into C++ would directly and indirectly result
in huge revenue increases for that company. In fact, it is to that
company's benefit to not have C++ be portable. If it is non-portable,
causes many issues, requires more design "tools", etc, that is all
activity. And activity in the software space translates to revenue for
any company that supports that activity, whether it is Perrier,
International Paper, Bic, Air Bus, Hilton Hotels, 3M, Sharpee, XYZ GC
Optimization Tools, Inc., whatever. There is a Belgian expression that
accurately characterizes what is going on with the new trend in "sloppy
kill-the-type-system mix-and-match coding style" that is going on
today. Unfortunately, its vulgarity prevents me from writing it int his
post, but essentially, it says that, when you are done doing what you
were doing, nothing is really accomplished, but everyone feels like it
has. I've spend more time in the past 6 months help people with GC
issues in languages that I don' t even know than I have spent on
related memory issues in my entire lifetime of C and C++. If I were to
add up the money wasted in salary for those people doing ..whatever it
is they are doing...it is simply huge.

> Fortunately, the C++ committee can read the writing on the wall as well
> as anyone: manual memory management is far too error-prone, produces
> programs that are far too expensive to debug and maintain, and even
> fails to deliver on the type safety guarantees of the language itself,
> to be presented as a serious alternative to automated memory
> management.

Failure of programmer or failure of language. I say failure of
programmer.

> C++ without any form of automated memory management cannot be taken
> seriously as a commercial-grade computer programming language today,
> and even less so, tomorrow.

I might start believe this statement when GC proponents start writing
their GC's in a language other than C++.

-Le Chaud Lapin-

Francis Glassborow

unread,
Dec 28, 2006, 1:56:21ā€ÆPM12/28/06
to
In article <1167244583.9...@i12g2000cwa.googlegroups.com>, Greg
Herlihy <gre...@pacbell.net> writes

>C++ without any form of automated memory management cannot be taken
>seriously as a commercial-grade computer programming language today,
>and even less so, tomorrow.


I disagree. C++ without the option of GC is certainly less attractive
than one with that option (which is why I am on the side of those
wanting implementations to be required to support GC but not at the
expense of supporting current code)

I know there are those who cannot imagine how one could write reliable,
robust code without GC. OTOH there are those who cannot imagine how one
could write reliable robust code with GC. They are both right for there
own problem domains and coding styles. But C++ should be able to support
both.

--
Francis Glassborow ACCU
Author of 'You Can Do It!' and "You Can Program in C++"
see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects

Mathias Gaunard

unread,
Dec 28, 2006, 1:58:19ā€ÆPM12/28/06
to
Greg Herlihy wrote:

> In comparison, the typical memory problems of a C++ program are far
> more serious: memory leaks, heap corruption, memory "stomping", invalid
> output, "crashes" far removed from the site of the error - the variety
> of potential C++ memory-management errors is practically infinite, and
> uniformly disasterous.

None of this should happen if you follow good programming practices.
They can only happen when interfacing with legacy, non RAII and
exception unsafe code.

A simple and good C++ way to code is to use RAII, where each object owns
its own resources.
With RAII, you prefer static allocation on automatic storage.
If for some reason, you need dynamic allocation, you do it in the
constructor of an object and free it in its destructor.

This very simple approach guarantees basic exception safety, and
produces very often strong exception safety too.


If you need transfer, this is not much more complicated.
You will usually need to do dynamic allocation on the free storage and
handle pointers through auto_ptr and friends.
You can also transfer resources using swap functions or the soon to come
move semantics.


The only place where GC helps is when doing data sharing and when the
data should be freed when there is no need to keep it anymore.
If there is no need to free the data once it's not used, or if it's
assumed the data will be useful for the whole program, a simple
singleton owning the resources and providing references to them would do.

Examples of uses are resources such as fonts, textures or models, used
by various objects. Loading the resources one time per object that uses
them is of course a waste, and just keeping them in memory when it's not
used anymore could actually be seen as a leak.

For that, people usually use refcounting as of now. (through shared_ptr
for example, but I also have seen an interesting flyweight framework
some time ago)
GC is just a possible optimization.

The main problem people are concerned with adding GC to the language is
that people may (and will) begin to use resource sharing when no sharing
is needed at all. This will be not only suboptimal but also may lead to
problems because of the undeterministic nature of GC.

I personally believe the approach of the current proposal from Hans
Boehm is wrong. Garbage collection should be a separate feature, not a
toggleable mode for new/delete and friends.
That proposal would however be very useful for C.


>
> Unless C++ is intended to become a programming language exclusively for
> hobbyists and others who write programs for their own enjoyment - then
> the C++ language has to evolve from its 80s-era origins if it is to
> remain economically competitive as a programming language today.

You're being wrong in believing there are only two kinds of C++ users:
hardcore C++ loving enthusiasts and economically driven people whose
main wish is to code simple things quickly to be the most profitable.

C++ especially tries to not to be too much influenced by the latter
group of people. C++'s aim is not to be a ready-made business solution.

> Fortunately, the C++ committee can read the writing on the wall as well
> as anyone: manual memory management is far too error-prone, produces
> programs that are far too expensive to debug and maintain, and even
> fails to deliver on the type safety guarantees of the language itself,
> to be presented as a serious alternative to automated memory
> management.

>From what you are saying it seems you've mostly only seen C-style code.
That's too bad, but unfortunetely most existing C++ code is that way.
Which is not only bad because it's unusable directly, but also because
people reading it also believe C++ is just C with Classes.

With modern C++, if your program is incorrect, most issues will already
be signaled at compile-time.
Especially if you use the metaprogramming part of the language.

> C++ without any form of automated memory management

C++ has automatic memory management, it's called the automatic storage.
Also known as "the stack".
The stack, though, can only store objects which size is known at
compile-time. An alternative stack which allows dynamic sizes is also
possible.
However, there is still one problem with the whole stack concept: when
moving an object to another scope, you need to copy it. As such it is
not good if you need to do lots of transfers of data (which can be
solved by a free store) or data sharing (where GC comes to use).

> cannot be taken
> seriously as a commercial-grade computer programming language today,
> and even less so, tomorrow.

You may not have noticed it, but C++ isn't a commercial product.

Francis Glassborow

unread,
Dec 28, 2006, 2:09:09ā€ÆPM12/28/06
to
In article <1167258570.5...@79g2000cws.googlegroups.com>,
Nemanja Trifunovic <ntrif...@hotmail.com> writes

>
>Le Chaud Lapin wrote:
>> The purpose of this post is to provide a bit of empirical evidence that
>> GC is no panacea, and that adding it to C++ might do more harm than
>> good.
>
>I agree with most of the points from your post, but there is nothing to
>worry about: C++ is not and will *never* be a garbage-collected
>language. It is possible that we see optional garbage collection added
>to the language, but I doubt even that will happen.

I would lay heavy odds that you are mistaken. Mandatory optional GC
(i.e. compilers are required to provide it if the programmer wants it)
is almost certain to be part of any multi-threading option and if the
next version of C++ does not have explicit support for efficient
multi-threading on multi-core processors it will be a dying language.

--
Francis Glassborow ACCU
Author of 'You Can Do It!' and "You Can Program in C++"
see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects

Zeljko Vrba

unread,
Dec 28, 2006, 2:06:36ā€ÆPM12/28/06
to
"Greg Herlihy" <gre...@pacbell.net> writes:
>
> In comparison, the typical memory problems of a C++ program are far
> more serious: memory leaks, heap corruption, memory "stomping", invalid
> output, "crashes" far removed from the site of the error - the variety
> of potential C++ memory-management errors is practically infinite, and
> uniformly disasterous.
>

I would like to see "opt-in" GC, but your arguments lead to believe that GC
would solve all of these problems. Which is not true in a language that
permits arbitrary pointer arithmetic and conversion from integers to pointers.
No GC can solve these problems. (HW support would help, see below).

Of all these errors, GC would solve only memory leaks and _some_ of the
crashes that are far from the site of error. The latter would be better
"solved" by modifying operator delete to set the pointer to NULL. It would at
least somewhat raise the bar for unlimited propagation of mistakes of the type

delete blah;
...
return blah;

Buffer overruns et al _are_ already easily solvable in segmented memory model
with hardware checks (a'la i386 segments).

<rant>
Sadly, AMD has, in its infinite wisdom, killed segmentation limit checks in
64-bit mode. They would be much better off if they made it faster and
expanded the number of segment registers, so that 1 segment per allocated
object becomes feasible. _That_ would be proper "virus protection", and not
their meager non-execute page protection bit they advertised.
</rant>

Francis Glassborow

unread,
Dec 28, 2006, 2:09:33ā€ÆPM12/28/06
to
In article <1167259835....@i12g2000cwa.googlegroups.com>, Le
Chaud Lapin <jaibu...@gmail.com> writes

>Francis Glassborow wrote:
>> I am pretty certain that none of them regard it as compulsory other than
>> that it should be required that implementations support GC (not that
>> does not mean anyone has to use it :)
>
>But Francis,
>
>Don't you think that this will cause a lot of confusion about how to
>best handle memory management? What about the the reputation of the
>language?

I have snipped the rest because they are largely FUD. I know that
current education as regards programming has a lot to be desired but
refusing ot provide support for GC will not help. Most of the next
generation of students will have been used to using a GC supporting
language.

I see a certain analogy to pointers, except this time in reverse. C++
has pointers but there use is largely optional (I can and do write large
amounts of code without ever using an explicit pointer) However pointers
are in the language for two reasons: support of legacy code from C,
support for low-level programming. Raw pointers should, IMO, be learnt
later rather than earlier and used only when the task needs them (and
pointer arithmetic would be rare outside low-level classes)

I would be happy to have GC the default for inexperienced and incidental
programmers (ones for whom programming is just a necessary tool for
their main work) and leave explicit memory management to those who need
it.

In the domain of multi-threaded code, GC is a definite advantage to
incidental programmers (and would probably reduce errors from those
'expert' programmers who actually know less than they think they do.)

I think that the overwhelming majority of programmers do not actually
appreciate how multi-core (or multi-CPU) hardware changes the playing
field. Disabling one core for a moment might be acceptable, but within
10 years we will be dealing with entry-level hardware with 8, 16 or even
32 cores and disabling 7 out of 8 will not be acceptable in many problem
domains.


--
Francis Glassborow ACCU
Author of 'You Can Do It!' and "You Can Program in C++"
see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects

Edward Diener No Spam

unread,
Dec 28, 2006, 2:01:34ā€ÆPM12/28/06
to
Greg Herlihy wrote:
> Le Chaud Lapin wrote:
>> Yet, when a programmer
>> uses the GC model, they might experience the following problems:
>>
>> * An OutOfMemoryException is thrown.
>> * The process is using too much memory for no obvious reason that
>> you can determine.
>> * It appears that garbage collection is not cleaning up objects
>> fast enough.
>> * The managed heap is overly fragmented.
>> * The application is excessively using the CPU.
>>
>> All of these symptoms make me wary, but the second (*) is most
>> impressive... "for no obvious reason that you can determine". The
>> last word in this sentence, "determine", is closely related to another
>> word, "determinism", a feature of C++ that is probably the basis for
>> having never experienced any of these problems in C++.
>
> In comparison, the typical memory problems of a C++ program are far
> more serious: memory leaks, heap corruption, memory "stomping", invalid
> output, "crashes" far removed from the site of the error - the variety
> of potential C++ memory-management errors is practically infinite, and
> uniformly disasterous.

The use of smart pointers and containers has negated nearly all of the
situations cited above. Of course for those who do not use these
facilities, the above situations still exist.

OTOH the alarmist view of GC memory management by the OP is also heavily
weighted toward things which almost never happen. Nevertheless,
countering the biased, alarmist view of the OP with a biased, alarmist
view of your own does not help your argument either.

Clearly GC as an optional part of C++ has possibilities, in particular
to handle cross-referenced pointers ( and references ). OTOH since C++
through RAII has superior handling of resources than any pure GC, or
even current partial GC, language, having non-GC RAII type classes go
away under a C++ GC implementation is most probably not going to happen
by any means.

In a long thread on comp.std.c++ many months ago Mr. Alexandrescu argued
for consideration of the idea of an optional GC implementation as part
of C++, with myself agreeing but believing that this would only be
successful if the syntax for allocation of GC objects as opposed to
non-GC objects could in its default implementation remain completely
transparent to the programmer, being automatically controlled instead by
the type of the object, ie. whether the particular object's class was an
RAII class or not.

The proposal of the idea of a GC implementation for C++ was not an
argument for forcing GC down the throat of all programmers nor was it an
argument against GC either. Certainly GC in C++ must remain completely
optional in the spirit of C++ if it ever exists as part of the official
language/library specification.

But for those who would wish to use it if it ever occurs in C++ I want
to reiterate the argument that unless it can at least by default be made
completely syntactically transparent to a programmer, no C++ programmer
is going to use it and write code where with every dynamically allocated
object a different syntax must be used to create objects depending on
whether one wants to dynamically allocate the object via GC or not. At
least I, given the smart pointer implementation of boost::shared_ptr,
will never use such convoluted syntax in a C++ language where GC can
optionally exist. However a default syntax where the programmer
allocates a new object and, if it is an RAII, it becomes a smart
pointer, while if it is not RAII it becomes a GC allocation, could I
think be successful in the C++ world.

Le Chaud Lapin

unread,
Dec 28, 2006, 2:07:34ā€ÆPM12/28/06
to
Nemanja Trifunovic wrote:
> I agree with most of the points from your post, but there is nothing to
> worry about: C++ is not and will *never* be a garbage-collected
> language. It is possible that we see optional garbage collection added
> to the language, but I doubt even that will happen.

Hi Nemanja,

What does "added to the language" mean?

-Le Chaud Lapin-

Walter Bright

unread,
Dec 28, 2006, 2:58:33ā€ÆPM12/28/06
to
Le Chaud Lapin wrote:
> Greg Herlihy wrote:
>> In comparison, the typical memory problems of a C++ program are far
>> more serious: memory leaks, heap corruption, memory "stomping", invalid
>> output, "crashes" far removed from the site of the error - the variety
>> of potential C++ memory-management errors is practically infinite, and
>> uniformly disasterous.
> The problems you listed are caused by programmers doing things they
> should not be doing.

True, we should not be writing buggy code <g>.

> The degree to which such problems manifest is
> directly proportional to the degree to which programmers persists in
> doing things that they should not be doing.

I can't disagree with that. More bugs in my code is usually
proportionately related to how many bugs I put in there.

> I've spend more time in the past 6 months help people with GC
> issues in languages that I don' t even know than I have spent on
> related memory issues in my entire lifetime of C and C++. If I were to
> add up the money wasted in salary for those people doing ..whatever it
> is they are doing...it is simply huge.

GC certainly is no panacea. But I've spent 25 years programming in C and
C++, and the worst, nastiest, most time consuming bugs by far have been
related to memory management. Memory management issues also consume a
large part of program design time. These issues don't disappear with GC,
but they are 70-80% reduced with GC. That gets my work done faster with
fewer bugs.

>> Fortunately, the C++ committee can read the writing on the wall as well
>> as anyone: manual memory management is far too error-prone, produces
>> programs that are far too expensive to debug and maintain, and even
>> fails to deliver on the type safety guarantees of the language itself,
>> to be presented as a serious alternative to automated memory
>> management.
> Failure of programmer or failure of language. I say failure of
> programmer.

If there's a consistent problem area of programming, then that is a
fertile area for improving the language, since it is a pipe dream to try
and improve the programmer.

>> C++ without any form of automated memory management cannot be taken
>> seriously as a commercial-grade computer programming language today,
>> and even less so, tomorrow.
> I might start believe this statement when GC proponents start writing
> their GC's in a language other than C++.

The D programming language's GC is written 100% in D.

Carlos Moreno

unread,
Dec 28, 2006, 2:53:12ā€ÆPM12/28/06
to
Le Chaud Lapin wrote:

>>In comparison, the typical memory problems of a C++ program are far
>>more serious: memory leaks, heap corruption, memory "stomping", invalid
>>output, "crashes" far removed from the site of the error - the variety
>>of potential C++ memory-management errors is practically infinite, and
>>uniformly disasterous.
>
> This viewpoint is very old in engineering and simply wrong. I've had
> computer science students complain that electrical engineering would be
> more fun if the math were not so complicated.
>
> The problems you listed are caused by programmers doing things they
> should not be doing.

You mean like programming in C with a C++ compiler? Yep, they should
*not* be doing that.

Maybe the preferred "new direction" that C++ should take would be
*completely* breaking the infamous compatibility with C (it is
already partially broken), instead of adding GC.

C++ memory management is already very "automatable" (not automatic,
but the facilities are there to make it very automatic --- RAII,
ctor/dtor to encapsulate memory management issues, auto_ptr and
shared_ptr, etc. etc. ... It is people still wanting to use
..c_srt() off an std::string to then use strcat/strcpy/etc. that
causes serious messes (and yes, the c_str()/strcat/etc example
is rather a figure of speech). Maybe *those* should be removed,
instead of GC added.

Carlos
--

Andreas Huber

unread,
Dec 28, 2006, 2:50:28ā€ÆPM12/28/06
to
Le Chaud Lapin wrote:
> That's why GC is so popular in C# and Java - there is the common
> misconception that it relieves them from having to think about memory
> management. The same happens in other disciplines.

Ok, I'll bite. How does GC not relieve you from "memory management", at
least some of it? Note that I'm not saying "resource management",
because it is well known that GC (as implemented in .NET & Java) cannot
relieve anyone from that.

--
Andreas Huber

When replying by private email, please remove the words spam and trap
from the address shown in the header.

Sean Kelly

unread,
Dec 28, 2006, 2:49:53ā€ÆPM12/28/06
to
Le Chaud Lapin wrote:
>
> If GC is added to the language proper:
...

> 3. Novice C++ users will likely lack the experience to properly judge,
> and being an educator, certainly you would agree that beginners often
> choose the path that they perceive to be that of least resistance.
> That's why GC is so popular in C# and Java - there is the common
> misconception that it relieves them from having to think about memory
> management. The same happens in other disciplines.

This would require the novice programmer to be somewhat familiar with
the C++ standard library, unless books start being published with the
preamble for enabling garbage collection much like they do with "using
std" now. And in my experience, many novice programmers simply aren't
that familiar with the C++ standard library. Not beyond perhaps
std::string and iostreams at any rate.

> But the vast majority of programmers do not program in isolation. Code
> is written, shared, maintained, passed along, prescribed, etc.
> Eventually, novice become experts, if not by skill, then by title.
> Then you end up with a situation where people who were once novices are
> prescribing designs that are inherently flawed because of the erroneous
> perception that memory does not have to be managed. Their lack of
> forethought in the design adversely affects the quality of the code.
> The poor code quality leads to instability, unreliability, and
> significant problems with maintainability. And this ultimately affects
> the reputation of C++.

So does unskilled programmers writing applications that crash and leak
like a sieve, which we've already got today.

I agree that many student programmers are never taught about memory
management, but that is more a factor of the language often used in the
classroom these days (ie. Java) than anything else. And this is
something that will come up in interviews. Graduates applying for a
C++ programming job will have to display some understanding of basic
memory management or they'll never get in the door.

> In the technical press, no one will write, "Engineers not appreciating
> the fundamental principle of good form falsely assumed that GC was a
> silver bullet and repeatedly concocted designs that were inherently
> defective, unwieldy, unstable, and unreliable using a language that
> readily supports good form, stability, and reliability: C++."
>
> Instead they will write, "C++ has serious memory management issues."

I would expect more of the technical press than this.

> After that, we anti-CG programmers could quickly find ourselves in a
> situation defending C++ against managerial revocation due to a
> degradation in integrity that was, ironically, induced by people who
> never understood the spirit of the language in the first place. This
> is a real possibility - just recently, the boss of a friend of mine in
> a software company declared that there would be a complete rewrite of
> all the code - in C#. The problem was COM ...someone got the idea 10
> years earlier that COM was the solution to all things grand - and it
> turned out that it was not, and the (wishfully-thinking) programmers
> made a horrific mess out of the code base, but C++ got a bad reputation
> for it. Now my friend could try to say to his boss - "Wait...the
> problem wasn't C++...the problem was that you used C++ in a manner that
> counter to its proper usage."..but that won't matter. What is done is
> done. C++ is out. C# is in.

For the project in question, a rewrite may have made the most sense.
There are a lot of contributing factors for such a decision, and
whether "C++ is a terrible language" was likely not one of them. The
considerations were probably more the cost of maintaining the current
codebase vs. the cost of a rewrite, availability of skilled C++
programmers vs. skilled C# programmers and/or the relative cost of C++
vs. C# programmers, the type of application being written, a possible
business relationship with Microsoft, etc.

> So I would rethink the notion that adding GC to the language is
> harmless because the use of it is optional. If that were the case,
> then we might as well add support for inline Lisp and many other things
> that an equal number of people would consider useful.

Personally, I don't find slippery slope arguments to be terribly
convincing, but I do appreciate your concern. As Greg Herlihy
mentioned however, garbage collection is simply the right choice in
many situations, and eliminating it as an option simply out of fear
that the unschooled masses may use it to tarnish the image of C++ seems
somewhat unreasonable.


Sean

Sergey P. Derevyago

unread,
Dec 28, 2006, 2:51:08ā€ÆPM12/28/06
to
Nemanja Trifunovic wrote:
> I agree with most of the points from your post, but there is nothing to
> worry about: C++ is not and will *never* be a garbage-collected
> language. It is possible that we see optional garbage collection added
> to the language, but I doubt even that will happen.
>
I see at least two possible interpretations of your statement above:
1. C++ will never be a DE JURE gc language.
2. C++ will never be a DE FACTO gc language.

It seems like you are talking about the first possible case. And I do agree
with your point in this meaning.
Unfortunately, the second case is the only case that has any real-life value.
And DE FACTO:
a) Typical "big bosses" are technically incompetent (beyond all repair).
b) Big bosses set the rules and they will certainly choose GC.

The bottom line is: C++ is definitely going to become a de facto
garbage-collected language. Sad but true.
--
With all respect, Sergey. http://ders.stml.net/
mailto : ders at skeptik.net

philip....@gmail.com

unread,
Dec 28, 2006, 2:49:24ā€ÆPM12/28/06
to
On Dec 28, 4:38 am, "Le Chaud Lapin" <jaibudu...@gmail.com> wrote:
> If GC is added to the language proper:
>
> 1. Advanced C++ programmers who never wanted GC in C++ will already
> know to abstain from using it as the general mechanism for memory
> management.

Maybe these programmers know that GC will not benefit any of their
current or future projects. Unfortunately many of us can't honestly say
this. Maybe this means I'm not "advanced"...

> 2. Advanced C++ programmers who wanted GC in C++...I have no idea what
> they would do... but I suspect that a significant number of them will
> use it as the general mechanism for memory management for x% of the
> time, where x is a number > 1 and < 100. Because we are all human,
> dx/dt will likely be > 0.

I think advanced C++ programmers will be able to judge the best memory
management technique to use for a given problem. When people came up
with smart pointers, I used them in my programs where I could. I'm sure
the same would be true of a garbage collector.

> 3. Novice C++ users will likely lack the experience to properly judge,
> and being an educator, certainly you would agree that beginners often
> choose the path that they perceive to be that of least resistance.
> That's why GC is so popular in C# and Java - there is the common
> misconception that it relieves them from having to think about memory
> management.

I do find that people who only know C# or Java do struggle a little
with memory related problems (like accidentally updating referenced
objects and shallow copying). These are things that a C++ programmer
would be unlikely to struggle with so I agree.

But I don't think that providing features in the language that make
programming easier should be seen as a bad thing.

Phil

Joe Seigh

unread,
Dec 28, 2006, 2:53:56ā€ÆPM12/28/06
to
Greg Herlihy wrote:
>
> In comparison, the typical memory problems of a C++ program are far
> more serious: memory leaks, heap corruption, memory "stomping", invalid
> output, "crashes" far removed from the site of the error - the variety
> of potential C++ memory-management errors is practically infinite, and
> uniformly disasterous.
>
> Unless C++ is intended to become a programming language exclusively for
> hobbyists and others who write programs for their own enjoyment - then
> the C++ language has to evolve from its 80s-era origins if it is to
> remain economically competitive as a programming language today.
> Fortunately, the C++ committee can read the writing on the wall as well
> as anyone: manual memory management is far too error-prone, produces
> programs that are far too expensive to debug and maintain, and even
> fails to deliver on the type safety guarantees of the language itself,
> to be presented as a serious alternative to automated memory
> management.
>

The arguments for garbage collection are a bit contrived and overblown.
There is no silver bullet. GC isn't going to make bad programmers into
good programmers. In some instances it can make things worse by turning
detectable errors into silent errors. If you think debugging a crash
that occurred much later than the actual error is difficult, try debugging
a bug caused by a silent error which will leave no clues at all as to
where the error occurred. I've debugged multi-threaded crash dumps
including ones where not finding the bug was not an option, where you
were not allowed to tell an enterprise customer that the bug "could
not be reproduced", a cop out which unfortunately way too may software
vendors use today. The hardest ones were the silent bugs without
crash dumps. Dumps where data is overwritten by other data? Hey,
that's a clue and much better than no clue at all. Unless you're
one of those software vendors who thinks that customers not being
able to prove that a bug exists is a good thing.

The actual value of GC, some implementations of it anyway, is as a form
of PDR for sharing data between threads. There are a number of problems
here. One is that you cannot pretend multi-threading does not exist for
the purpose of your base language definitions and then add multi-threading
on top of that and then expect that no problems will be caused by that. Another
problem is pretending that GC is totally distinct from smart pointers,
another form of PDR. So you end up with two solutions to the same problem
with different and inconsistent approaches taken w.r.t. the C++ language.
And some of the approaches may preclude alternatives. E.g., GC might become
optional but you might not be allowed to use alternate implementations of
GC. That can happen in part because pointer in a GC may look like regular
pointers, they aren't. In order for non conservative GC to work, it has
to know where the pointers are. Which means support by the compiler for
only certain implementations of GC. E.g. they only support pointers that
are equivalent to void* and can be dereferenced directly. Abstract pointer
support that would support any form of GC or smart pointer would be nice
and would avoid this sort of problem but I don't think that's going to happen.


--
Joe Seigh

When you get lemons, you make lemonade.
When you get hardware, you make software.

Ion GaztaƱaga

unread,
Dec 29, 2006, 3:53:36ā€ÆAM12/29/06
to
> I have snipped the rest because they are largely FUD. I know that
> current education as regards programming has a lot to be desired but
> refusing ot provide support for GC will not help. Most of the next
> generation of students will have been used to using a GC supporting
> language.
>
> I see a certain analogy to pointers, except this time in reverse. C++
> has pointers but there use is largely optional (I can and do write large
> amounts of code without ever using an explicit pointer) However pointers
> are in the language for two reasons: support of legacy code from C,
> support for low-level programming. Raw pointers should, IMO, be learnt
> later rather than earlier and used only when the task needs them (and
> pointer arithmetic would be rare outside low-level classes)

I was thinking about writing about this in comp.std.c++ this week, but
I can't resist joining this thread. The problem with "optional" is that
"optional" can mean many things. I find current proposal (N2128) very
discouraging. It proposes overloading "new" and "delete" so everyone
must design its generic designs to both garbage and non-garbage
collection environments (I must call delete always). On the other hand,
I can't count with deterministic resource liberation (something I
suppose also in STL containers) because my code can be used with
garbage collection. Really disturbing.

If a library returns a pointer, I don't know if its garbage collected
or I must free it. The type of the pointer is the same for GC memory or
manual memory allocation. Apart from that I must start tagging all my
classes with gc forbidden/gc strict, to avoid more than necessary
garbage search from the collector.

In my opinion, it's not true that we have several years of experience
on GC with C++. We have some libraries (Boehm GC, for example) that
makes our whole program garbage collected. The only widely used
language mixing GC and manual memory is Managed C++. And they chose to
use different pointer types and allocation functions to separate both
worlds. My opinion is that GC should be treated as a new smart pointer,
so that at compile time, I know if I should free that pointer or not
(gc_pointer). With such pointer and a new allocation function "gc_new"
I know that gc_pointer is much like shared_ptr with no deterministic
finalization.

Making raw pointers and new/delete garbage collected plus tagging all
standard classes is in my opinion, a bad idea with no previous
experience, because changes the semantics of my precompiled library
(that it's counting on C++ deterministic features) when linking it with
a garbage collected environment. And I don't want to start tagging my
classes as gc_forbidden to avoid this. Supporting raw pointers can also
limit the GC algorithms that can be used (can we use non-conservative,
compacting, algorithmthms?).

>From the proposal:

"Unlike the C++/CLI approach, transparent garbage collection allows
easy
\cut-and-paste" reuse of existing source code and object libraries
without
the need to modify their memory management or learn how to manipulate
two types of pointers."

I don't thing code migration should be the reason for that. Old c++
code is written for manual management. If that code has memory leaks,
let's fix them. For most data, we know its lifetime. For the rest,
let's have gc_pointer/gc_new. Just my 2 cents.

I was quite reluctant to GC some months ago (after all, I almost never
write "new[]" expressions, because I use STL containers, RAII, and the
stack) but after N2128, I'm really worried.

Regards,

Ion


--

Mirek Fidler

unread,
Dec 29, 2006, 4:07:13ā€ÆAM12/29/06
to

Le Chaud Lapin wrote:
> The purpose of this post is to provide a bit of empirical evidence that
> GC is no panacea, and that adding it to C++ might do more harm than
> good.

Well, it certainly seems to provide a good opportunity to repeat all
those old arguments again :)

Mirek

Mirek Fidler

unread,
Dec 29, 2006, 4:08:14ā€ÆAM12/29/06
to

Sergey P. Derevyago wrote:
> Nemanja Trifunovic wrote:
> > I agree with most of the points from your post, but there is nothing to
> > worry about: C++ is not and will *never* be a garbage-collected
> > language. It is possible that we see optional garbage collection added
> > to the language, but I doubt even that will happen.
> >
> I see at least two possible interpretations of your statement above:
> 1. C++ will never be a DE JURE gc language.
> 2. C++ will never be a DE FACTO gc language.
>
> It seems like you are talking about the first possible case. And I do agree
> with your point in this meaning.
> Unfortunately, the second case is the only case that has any real-life value.
> And DE FACTO:
> a) Typical "big bosses" are technically incompetent (beyond all repair).
> b) Big bosses set the rules and they will certainly choose GC.
>
> The bottom line is: C++ is definitely going to become a de facto
> garbage-collected language. Sad but true.

Actually, maybe the real problem of C++ future is that there is no big
company behind it. No big company -> no hype -> big technically
incompetent bosses go away...

Alternative approach is to create "community" hype (think Python), but
I am afraid C++ lost its moment long time ago (IMO, sometimes around
the moment it was "boosted" by STL).

Sad but true.

Mirek

Mirek Fidler

unread,
Dec 29, 2006, 4:07:46ā€ÆAM12/29/06
to

Walter Bright wrote:
> Le Chaud Lapin wrote:
> > I've spend more time in the past 6 months help people with GC
> > issues in languages that I don' t even know than I have spent on
> > related memory issues in my entire lifetime of C and C++. If I were to
> > add up the money wasted in salary for those people doing ..whatever it
> > is they are doing...it is simply huge.
>
> GC certainly is no panacea. But I've spent 25 years programming in C and
> C++, and the worst, nastiest, most time consuming bugs by far have been
> related to memory management. Memory management issues also consume a
> large part of program design time.

You must have been using completely different language than I did all
that time. But the one I was using was named "C++" too. What is going
wrong here?

Mirek

Carlos Moreno

unread,
Dec 29, 2006, 4:05:25ā€ÆAM12/29/06
to
Sean Kelly wrote:

>>3. Novice C++ users will likely lack the experience to properly judge,
>>and being an educator, certainly you would agree that beginners often
>>choose the path that they perceive to be that of least resistance.
>>That's why GC is so popular in C# and Java - there is the common
>>misconception that it relieves them from having to think about memory
>>management. The same happens in other disciplines.
>
> This would require the novice programmer to be somewhat familiar with

> the C++ standard library [...] And in my experience, many novice

> programmers simply aren't
> that familiar with the C++ standard library. Not beyond perhaps
> std::string and iostreams at any rate.

And vector, I bet.

But then, why would a beginner C++ programmer need anything beyond
string, vector, and streams?

That *is*, IMHO, the right way to go about starting with C++; not
pointers and all the madness now supported by the fact that the
beginners need not worry about anything because there's "daddy-GC"
that will be there to clean up after us, no matter what attrocities
we may have done. (that is, hypothetically speaking)

Carlos
--

Greg Herlihy

unread,
Dec 29, 2006, 4:19:07ā€ÆAM12/29/06
to
Joe Seigh wrote:
> Greg Herlihy wrote:
> >
> > In comparison, the typical memory problems of a C++ program are far
> > more serious: memory leaks, heap corruption, memory "stomping", invalid
> > output, "crashes" far removed from the site of the error - the variety
> > of potential C++ memory-management errors is practically infinite, and
> > uniformly disasterous.
> >
> > Unless C++ is intended to become a programming language exclusively for
> > hobbyists and others who write programs for their own enjoyment - then
> > the C++ language has to evolve from its 80s-era origins if it is to
> > remain economically competitive as a programming language today.
> > Fortunately, the C++ committee can read the writing on the wall as well
> > as anyone: manual memory management is far too error-prone, produces
> > programs that are far too expensive to debug and maintain, and even
> > fails to deliver on the type safety guarantees of the language itself,
> > to be presented as a serious alternative to automated memory
> > management.
> >
>
> The arguments for garbage collection are a bit contrived and overblown.
> There is no silver bullet. GC isn't going to make bad programmers into
> good programmers.

Sure it will. By redefining what it takes to be a "good" programmer,
garbarge collection will have precisely such an effect. Namely, today's
"good" programmer needs to master a whole set of skills that tomorrow's
good programmer will have no use for - because garbage collection will
have rendered such knowledge - obsolete. Just as being a "good" driver
used to require the ability to shift gears by hand, the invention of
the automatic transmission made it is possible to be a good driver
without possessing the ability to shift gears by hand. And shifting
gears by hand is no more a requisite driving skill any more than
performing memory management by hand is a requisite programming skill.

> In some instances it can make things worse by turning
> detectable errors into silent errors. If you think debugging a crash
> that occurred much later than the actual error is difficult, try debugging
> a bug caused by a silent error which will leave no clues at all as to
> where the error occurred. I've debugged multi-threaded crash dumps
> including ones where not finding the bug was not an option, where you
> were not allowed to tell an enterprise customer that the bug "could
> not be reproduced", a cop out which unfortunately way too may software
> vendors use today.

You're conflating debugging multi-threaded programs with the
single-threaded garbage-collected model that is the one actually being
discussed. So it's hard to imagine how any observation concerning the
former could be at all relevant or offer any insight at all into the
usefulness of garbage collection to a C++ program as one exists today.

> The hardest ones were the silent bugs without
> crash dumps. Dumps where data is overwritten by other data? Hey,
> that's a clue and much better than no clue at all. Unless you're
> one of those software vendors who thinks that customers not being
> able to prove that a bug exists is a good thing.

If a bug is not detectable, then by what measure does the bug even
exist?

Greg


--

Nemanja Trifunovic

unread,
Dec 29, 2006, 4:21:14ā€ÆAM12/29/06
to

Francis Glassborow wrote:
> In article <1167258570.5...@79g2000cws.googlegroups.com>,
> Nemanja Trifunovic <ntrif...@hotmail.com> writes
> >
> >Le Chaud Lapin wrote:
> >> The purpose of this post is to provide a bit of empirical evidence that
> >> GC is no panacea, and that adding it to C++ might do more harm than
> >> good.
> >
> >I agree with most of the points from your post, but there is nothing to
> >worry about: C++ is not and will *never* be a garbage-collected
> >language. It is possible that we see optional garbage collection added
> >to the language, but I doubt even that will happen.
>
> I would lay heavy odds that you are mistaken. Mandatory optional GC
> (i.e. compilers are required to provide it if the programmer wants it)
> is almost certain to be part of any multi-threading option and if the
> next version of C++ does not have explicit support for efficient
> multi-threading on multi-core processors it will be a dying language.
>

So you are saying efficient multithreading is not possible without GC?


--

Le Chaud Lapin

unread,
Dec 29, 2006, 4:24:32ā€ÆAM12/29/06
to
Stephen Howe wrote:
> Your post is interesting, particularly the articles of what happening in the
> ..NET world concerning memory management and RC. And I agree with you on the
> damage of adding GC to C++. But I regard it as alarmist, the addition of GC
> to C++ will _never_ happen except as an optional component which was
> Bjarne's original vision (and to date in tihs newsgroup, I have never seen a
> GC aficionado talk about the optionality of GC for C++ which leads me to
> believe they regard it as compulsory). Optional I can live with. At this
> point it becomes political in whether the "option" is purely by the
> programmer as well as the vendor.

Optional all the way around seems reasonable.

GC, in the form of a library / framework that does not fundamentally
change the language, might be the best option. That way, if it turns
out that the GC people were wrong, at least the language would not have
been irrevocably altered.

-Le Chaud Lapin-

Nemanja Trifunovic

unread,
Dec 29, 2006, 4:21:36ā€ÆAM12/29/06
to

Sergey P. Derevyago wrote:
> I see at least two possible interpretations of your statement above:
> 1. C++ will never be a DE JURE gc language.
> 2. C++ will never be a DE FACTO gc language.
>
> It seems like you are talking about the first possible case.

Hi Sergey.

Actually, I mean 2. :) Big bosses who like GC have already switched to
Java and C#. I can hardly imagine a situation when it makes sense to
use C++ with a non-deterministic GC.

Nemanja Trifunovic

unread,
Dec 29, 2006, 4:20:43ā€ÆAM12/29/06
to

>
> What does "added to the language" mean?
>
> -Le Chaud Lapin-
>
>

I mean what Francis said above: "compilers are required to provide it
if the programmer wants it". As I said, that *may* happen, but I know
very few C++ programmers interested in using GC with C++, so even if it
is added odds are very few people will ever use it.

Of course, that's only my personal opinion, inspired partially with the
fate of C99.

Le Chaud Lapin

unread,
Dec 29, 2006, 2:27:17ā€ÆPM12/29/06
to

Francis Glassborow wrote:
[snippage]

> I would be happy to have GC the default for inexperienced and incidental
> programmers (ones for whom programming is just a necessary tool for
> their main work) and leave explicit memory management to those who need
> it.

Like others have stated, I think this is naive. GC and RAII will not
co-exist orthogonally, they will mix with a vengeance. If it is truth
that man pro-GC people do not properly use RAII (and I do believe
this), there is no reason to believe that the situation will get better
with GC.

I think we are kidding ourselves here. We speak of GC and all the
intricate details it brings forth, but there is something more
fundamental going on, and that is how to properly structure systems.
Many programmers do not know how to properly structure systems (that's
what separates engineering from programming), so they engage in style
of code-writing that could best be described as meandering. Naturally,
GC is useful for this style of thinking - it is a comfortable to think
there is a maid that will come up behind you and create any mess you
make.

Note that I am *not* trying to keep GC out of C++ to get these
programmers to learn how to structure systems better. I am saying what
Stephen Howe pointed out so accurately - **We already have a memory
management system in C++.***

> In the domain of multi-threaded code, GC is a definite advantage to
> incidental programmers (and would probably reduce errors from those
> 'expert' programmers who actually know less than they think they do.)

I did a grep for number of classes in my system. It is now over 150,
if you include the embedded classes, but I *never* worry about memory
management issues. I know that I could probably scale my system by a
factor of 1000, do a recompile, and there still will be no memory
management issues. How do I know this? RAII. It is what allows
scalability. GC, on the other hand, would have let to a massive
indeterminate, mess. This is what the C#.NET people are starting to
discover empirically.

> I think that the overwhelming majority of programmers do not actually
> appreciate how multi-core (or multi-CPU) hardware changes the playing
> field. Disabling one core for a moment might be acceptable, but within
> 10 years we will be dealing with entry-level hardware with 8, 16 or even
> 32 cores and disabling 7 out of 8 will not be acceptable in many problem
> domains.

Probably. But how does this relate to GC?

-Le Chaud Lapin-


--

Nemanja Trifunovic

unread,
Dec 29, 2006, 2:28:47ā€ÆPM12/29/06
to

Walter Bright wrote:
> But I've spent 25 years programming in C and
> C++, and the worst, nastiest, most time consuming bugs by far have been
> related to memory management. Memory management issues also consume a
> large part of program design time. These issues don't disappear with GC,
> but they are 70-80% reduced with GC. That gets my work done faster with
> fewer bugs.

I have spent only 12 years programming in C++ (plus a couple more with
C), and don't even remember having problems related to memory
management. The biggest problems I have seen come from poor project
management (pun intended), especially changing requirements and
unfortunatelly no garbage collector can help with them.

Le Chaud Lapin

unread,
Dec 29, 2006, 2:28:16ā€ÆPM12/29/06
to
Andreas Huber wrote:
> Ok, I'll bite. How does GC not relieve you from "memory management", at
> least some of it? Note that I'm not saying "resource management",
> because it is well known that GC (as implemented in .NET & Java) cannot
> relieve anyone from that.

Memory is not infinite. I will repeat what Microsoft wrote about their
own language/framework:

You must understand, this is not some C++ lover/C# basher writing this.
This is Microsoft writing about a language/framework for which they
had 100% control over the design.

"Uncovering and correcting memory issues in managed applications can be
difficult. "

I laugh a small bit each time I read this sentence. First, one of the
biggest selling points of managed applications was GC. The other
selling point, which was probably one of greatest marketing drugs in
the 20th Century was "managed", giving the idea that it is somehow
better than "unmanaged". So here we have that memory, managed, and
difficult, are all be used in the same sentence, being written by the
very organization that claimed to make these things not difficult.

See again the problems:

* An OutOfMemoryException is thrown.
* The process is using too much memory for no obvious reason that
you can determine.
* It appears that garbage collection is not cleaning up objects
fast enough.
* The managed heap is overly fragmented.
* The application is excessively using the CPU.

Any engineer who designs a program that contains these problems in such
significant quantities as to warrant an article being written about it
should be ashamed of him/herself.

-Le Chaud Lapin-

Reference:

http://msdn.microsoft.com/msdnmag/issues/06/11/CLRInsideOut/default.aspx


--

Carlos Moreno

unread,
Dec 29, 2006, 2:39:21ā€ÆPM12/29/06
to
Walter Bright wrote:

> GC certainly is no panacea. But I've spent 25 years programming in C and
> C++, and the worst, nastiest, most time consuming bugs by far have been
> related to memory management. Memory management issues also consume a
> large part of program design time. These issues don't disappear with GC,
> but they are 70-80% reduced with GC.

I have to strongly disagree with these numbers; *memory management*
problems tend to be nasty and hard-to-deal-with. But GC --- and
correct me if I'm wrong --- only addresses memory leaks, which is
by far, but really really really far, the least problematic of the
categories of memory management issues.

Badly managed pointer arithmetic, memory overwrite, buffer overflows,
double-deletion, dereferencing invalid/uninitialized/deleted/NULL
pointers, etc. etc. etc. are the *real* problems regarding memory
management. GC has absolutely nothing to do with any of those.

Memory leaks are relatively (actually, very) easy to find, and
very easy to fix (provided an absolute minimum of sanity in the
design and the coding); and, ironically (ironically from the
point of view of wanting to add GC to C++), with C++ it is
extremely easy to *prevent*.

> If there's a consistent problem area of programming, then that is a
> fertile area for improving the language, since it is a pipe dream to try
> and improve the programmer.

I have to agree on this --- but you have to agree also (at least
with the setiment) with Dijkstra's essay "How to Program When you
Can't" (I probably misquoted the title).

But putting that aside, I believe that GC is far from solving the
memory management problems --- I firmly believe that the only
contribution from GC would be increasing/promoting sloppiness
and inviting increasingly lower-skilled programmers into the C++
game. Is that what we want? Do we want to win the popularity
contest? (because if we do, then accepting incomeptent and
unskilled programmers into the game is an absolute necessity)

If --- and I can not stress how much I'm saying this only for
the sake of the argument --- Java is indeed a less error-prone
and more effective/productive programming language, it would
be due to the lack of pointer arithmetic (or rather, in a
sense, the lack of pointers), and not for the GC.

>>> C++ without any form of automated memory management cannot be taken
>>> seriously as a commercial-grade computer programming language today,
>>> and even less so, tomorrow.

When did they change the world?? I just went to sleep and I
wake up just after the statement world.swap(twilight_zone)??!!!

I was so happy thinking that fortunately and finally it had been
settled a few decades ago that among the minimum requirements
for a *serious* prorgamming language is being compiled, requiring
variable declarations, and not having the big joke that I've
always found GC to be, and now everyone wants interpreted
languages with GC???

What then? For the next revision of C++ people are going to
want to make it interpreted instead of compiled???!!!! And
I would expect that after that, we get rid of the annoyiong
variable declarations and the ridiculous data types.

Carlos
--

Le Chaud Lapin

unread,
Dec 29, 2006, 2:31:39ā€ÆPM12/29/06
to
Carlos Moreno wrote:
> Le Chaud Lapin wrote:
> You mean like programming in C with a C++ compiler? Yep, they should
> *not* be doing that.

Yep.

> Maybe the preferred "new direction" that C++ should take would be
> *completely* breaking the infamous compatibility with C (it is
> already partially broken), instead of adding GC.

Yes.

> C++ memory management is already very "automatable" (not automatic,
> but the facilities are there to make it very automatic --- RAII,
> ctor/dtor to encapsulate memory management issues, auto_ptr and
> shared_ptr, etc. etc. ... It is people still wanting to use
> ..c_srt() off an std::string to then use strcat/strcpy/etc. that
> causes serious messes (and yes, the c_str()/strcat/etc example
> is rather a figure of speech). Maybe *those* should be removed,
> instead of GC added.

I saw this in real C++ code, using maybe 500 times. the .cstr() thing.


There is also the issue of libraries. STL is deficient. I could name
10-12 classes that are *absolutely fundamental* in systems engineering,
and not only does C++ not have them, I don't know if anyone out there
is even acknowledging that they do not exist. This is another reason
for sloppy, operator new(), non-RAII type coding..the programmer is
actually trying to create data structures that are fundamental, only we
do not know of them yet.

-Le Chaud Lapin-

Le Chaud Lapin

unread,
Dec 29, 2006, 2:30:48ā€ÆPM12/29/06
to

Sean Kelly wrote:
> Le Chaud Lapin wrote:
> > Instead they will write, "C++ has serious memory management issues."
>
> I would expect more of the technical press than this.

Why? It's much more sensational to write things that people want to
hear rather than the truth.

> For the project in question, a rewrite may have made the most sense.
> There are a lot of contributing factors for such a decision, and
> whether "C++ is a terrible language" was likely not one of them. The
> considerations were probably more the cost of maintaining the current
> codebase vs. the cost of a rewrite, availability of skilled C++
> programmers vs. skilled C# programmers and/or the relative cost of C++
> vs. C# programmers, the type of application being written, a possible
> business relationship with Microsoft, etc.

Yes...I am sure that is what went through the managers mind. But there
is illusion and there is truth. The illusion is that C# and GC will
make things better. The truth is that the software was just plain
sloppy. It behooves some of us to maintain the distinction between
illusion and truth.

Let me put it this way: in exactly 12 months, I have zero doubt that
their system will be just as poorly designed as the current system.

>
> Personally, I don't find slippery slope arguments to be terribly
> convincing, but I do appreciate your concern. As Greg Herlihy
> mentioned however, garbage collection is simply the right choice in
> many situations, and eliminating it as an option simply out of fear
> that the unschooled masses may use it to tarnish the image of C++ seems
> somewhat unreasonable.

For the 50th time. :)

Could some please give me a real example of such a system?

-Le Chaud Lapin-

Le Chaud Lapin

unread,
Dec 29, 2006, 2:32:10ā€ÆPM12/29/06
to

Sergey P. Derevyago wrote:
> Nemanja Trifunovic wrote:
> > I agree with most of the points from your post, but there is nothing to
> > worry about: C++ is not and will *never* be a garbage-collected
> > language. It is possible that we see optional garbage collection added
> > to the language, but I doubt even that will happen.
> >
> I see at least two possible interpretations of your statement above:
> 1. C++ will never be a DE JURE gc language.
> 2. C++ will never be a DE FACTO gc language.
>
> It seems like you are talking about the first possible case. And I do agree
> with your point in this meaning.
> Unfortunately, the second case is the only case that has any real-life value.
> And DE FACTO:
> a) Typical "big bosses" are technically incompetent (beyond all repair).
> b) Big bosses set the rules and they will certainly choose GC.
>
> The bottom line is: C++ is definitely going to become a de facto
> garbage-collected language. Sad but true.

The distinction you make is fundamental. And the fact that the
distinction will become irrelevant, as you point out, is fundamental.

That's why it is so important that we work to keep GC out of the
language until we have had a chance to see what it does to other
languages.

Thanks for making this clear,

-Le Chaud Lapin-

Mirek Fidler

unread,
Dec 29, 2006, 3:04:08ā€ÆPM12/29/06
to

Carlos Moreno wrote:

> But then, why would a beginner C++ programmer need anything beyond
> string, vector, and streams?

Well, even beginner C++ programmer needs to create a collection of
objects without defined copy operation from time to time.

--
Mirek Fidler
U++ team leader. http://www.ultimatepp.org

Bredy (Ondrej Novak)

unread,
Dec 29, 2006, 3:09:18ā€ÆPM12/29/06
to
{ Please limit your text to 70 columns or so.
This article is reformatted to fit within 72 columns. -mod }

If anybody needs GC in C++, just write it!

You have all tools that you need. You have smart pointers that can
register itself into GC, you can overload new and delete to register
memory block into GC. You can create reference graph in GC library and
start thread, that will do garbage collecting at background (tracks
allocations, processes reference graph and calls delete on unreferenced
objects.

You will have the complette control on this GC.

:o)

bredy.jinak.cz

--

Ion GaztaƱaga

unread,
Dec 29, 2006, 3:09:47ā€ÆPM12/29/06
to
> GC certainly is no panacea. But I've spent 25 years programming in C and
> C++, and the worst, nastiest, most time consuming bugs by far have been
> related to memory management. Memory management issues also consume a
> large part of program design time. These issues don't disappear with GC,
> but they are 70-80% reduced with GC. That gets my work done faster with
> fewer bugs.

That's not my case (I generally spend more time designing and fixing
logic errors than fixing memory leaks) but couldn't this be fixed with
an integrated leak detector? If C++ offers an standard leak detector
for special debug builds (saying where and when was memory allocated
and not freed, or reused after being freed) you can solve most of your
problems and also detect logic errors (for example if calling delete[]
frees more resources like sockets, files...). IBM/Rational Purify
(garbage collection based, I think) is a good example for this
(although it's very slow). żWill garbage collection will fix buffer
overruns or access to uninitialized memory? If the main purpose is to
avoid leaks, let's have a leak detector.

If we also need some memory allocation with uncertain lifetime, let's
have a garbage collected allocation method/pointer. But that's not the
same as making the whole language (new/delete) garbage collected.

Regards,

Ion

Francis Glassborow

unread,
Dec 29, 2006, 3:14:20ā€ÆPM12/29/06
to
In article <1167351135.0...@73g2000cwn.googlegroups.com>,
Nemanja Trifunovic <ntrif...@hotmail.com> writes

>> I would lay heavy odds that you are mistaken. Mandatory optional GC
>> (i.e. compilers are required to provide it if the programmer wants it)
>> is almost certain to be part of any multi-threading option and if the
>> next version of C++ does not have explicit support for efficient
>> multi-threading on multi-core processors it will be a dying language.
>>
>
>So you are saying efficient multithreading is not possible without GC?

Not quite, I am saying that efficient and safe multi-threaded
programming will require exceptional skills in the future if it is done
without GC. Manual memory management in a MT program either cripples
modern hardware (by locking -- which is not cheap when that results in
suspending 90% of your CPU power) or consumes an inordinate amount of
highly skilled programmer time.

--
Francis Glassborow ACCU
Author of 'You Can Do It!' and "You Can Program in C++"
see http://www.spellen.org/youcandoit
For project ideas and contributions:
http://www.spellen.org/youcandoit/projects

Sergey P. Derevyago

unread,
Dec 29, 2006, 3:11:54ā€ÆPM12/29/06
to
Nemanja Trifunovic wrote:
> So you are saying efficient multithreading is not possible without GC?
>
It's a wide-spread mistake.
I've discussed this issue several times in comp.lang.c++.moderated and
comp.programming.threads

--
With all respect, Sergey. http://ders.stml.net/
mailto : ders at skeptik.net

[ See http://www.gotw.ca/resources/clcm.htm for info about ]

Sergey P. Derevyago

unread,
Dec 29, 2006, 3:11:23ā€ÆPM12/29/06
to
Nemanja Trifunovic wrote:
> I can hardly imagine a situation when it makes sense to
> use C++ with a non-deterministic GC.
>
All successful managers are politicians.
And pure technical reasons don't have any value when it comes to someone's
personal career.

P.S. I understand that this message has no particular connections to the C++
grounds. But I feel obliged to elaborate my point w.r.t. real-world GC issues.


--
With all respect, Sergey. http://ders.stml.net/
mailto : ders at skeptik.net

[ See http://www.gotw.ca/resources/clcm.htm for info about ]

Francis Glassborow

unread,
Dec 29, 2006, 3:13:58ā€ÆPM12/29/06
to
In article <1167351361....@k21g2000cwa.googlegroups.com>,
Nemanja Trifunovic <ntrif...@hotmail.com> writes

>I mean what Francis said above: "compilers are required to provide it
>if the programmer wants it". As I said, that *may* happen, but I know
>very few C++ programmers interested in using GC with C++, so even if it
>is added odds are very few people will ever use it.


No, only very few people that you currently know :-) Just as very few
people wanted to use templates in 1989 :-) And even fewer people wanted
to use metaprogramming during the 1990s. Until a facility is available
it tends to be unwanted.


--
Francis Glassborow ACCU
Author of 'You Can Do It!' and "You Can Program in C++"
see http://www.spellen.org/youcandoit
For project ideas and contributions:
http://www.spellen.org/youcandoit/projects

Le Chaud Lapin

unread,
Dec 29, 2006, 4:42:22ā€ÆPM12/29/06
to
Greg Herlihy wrote:
> Sure it will. By redefining what it takes to be a "good" programmer,
> garbarge collection will have precisely such an effect. Namely, today's
> "good" programmer needs to master a whole set of skills that tomorrow's
> good programmer will have no use for - because garbage collection will
> have rendered such knowledge - obsolete. Just as being a "good" driver
> used to require the ability to shift gears by hand, the invention of
> the automatic transmission made it is possible to be a good driver
> without possessing the ability to shift gears by hand. And shifting
> gears by hand is no more a requisite driving skill any more than
> performing memory management by hand is a requisite programming skill.

This analogy is not entirely appropriate. We they gave us automatic
transmissions, they took away the clutch. With C++, we will end up
with both the automatic transmission and the clutch. [On an amusing
note, I took some of my French friends on a road trip to Canada. One
of them had never been in a car with an automatic transmission, and
tried to down-shift at 40mph. Thank God for dog teeth.]

> > In some instances it can make things worse by turning
> > detectable errors into silent errors. If you think debugging a crash
> > that occurred much later than the actual error is difficult, try debugging
> > a bug caused by a silent error which will leave no clues at all as to
> > where the error occurred. I've debugged multi-threaded crash dumps
> > including ones where not finding the bug was not an option, where you
> > were not allowed to tell an enterprise customer that the bug "could
> > not be reproduced", a cop out which unfortunately way too may software
> > vendors use today.
>
> You're conflating debugging multi-threaded programs with the
> single-threaded garbage-collected model that is the one actually being
> discussed. So it's hard to imagine how any observation concerning the
> former could be at all relevant or offer any insight at all into the
> usefulness of garbage collection to a C++ program as one exists today.

Well, he mentions multi-threading as the context, but the same thing
could happen without multi-threading. In fact, it is happening now.
You really should read the links I put in the OP. It's in plain
English: GC has issues that need to be addressed.

> > The hardest ones were the silent bugs without
> > crash dumps. Dumps where data is overwritten by other data? Hey,
> > that's a clue and much better than no clue at all. Unless you're
> > one of those software vendors who thinks that customers not being
> > able to prove that a bug exists is a good thing.
>
> If a bug is not detectable, then by what measure does the bug even
> exist?

Again, read the bullet points that Microsoft wrote in their article
about how GC causes strange problems. I will rewrite them here:

Reprint:

Another example is the current Visual Studio 2005 IDE start page:

http://msdn.microsoft.com/msdnmag/issues/06/11/CLRInsideOut/default.aspx

"Uncovering and correcting memory issues in managed applications can be
difficult. "

That sentence says it all. This is written written by a company that
had full control over the garbage collection system of a language it
created. Unlike C++, they had absolute control over the the memory
management system to mold it as they saw fit. Yet, when a programmer
uses the GC model, they might experience the following problems:

* An OutOfMemoryException is thrown.
* The process is using too much memory for no obvious reason that
you can determine.
* It appears that garbage collection is not cleaning up objects
fast enough.
* The managed heap is overly fragmented.
* The application is excessively using the CPU.

"memory issues" is a euphemism for "bugs".

-Le Chaud Lapin-

loufoque

unread,
Dec 29, 2006, 4:46:12ā€ÆPM12/29/06
to
Ion Gaztańaga wrote:

> I don't thing code migration should be the reason for that. Old c++
> code is written for manual management. If that code has memory leaks,
> let's fix them. For most data, we know its lifetime. For the rest,
> let's have gc_pointer/gc_new. Just my 2 cents.
>
> I was quite reluctant to GC some months ago (after all, I almost never
> write "new[]" expressions, because I use STL containers, RAII, and the
> stack) but after N2128, I'm really worried.

I guess we can still try to vote against it.
I think something similar to C++/CLI would be better, indeed.

Joe Seigh

unread,
Dec 29, 2006, 4:44:15ā€ÆPM12/29/06
to
Greg Herlihy wrote:

> Joe Seigh wrote:
>>
>
>
> You're conflating debugging multi-threaded programs with the
> single-threaded garbage-collected model that is the one actually being
> discussed. So it's hard to imagine how any observation concerning the
> former could be at all relevant or offer any insight at all into the
> usefulness of garbage collection to a C++ program as one exists today.

No, I'm saying that unless you're doing some sort of graph
theoretical algorithm programming, the arguments for GC in
a single threaded environment are somewhat contrived. But
if you want to pretend that threading doesn't exist and
that making decisions based on that will have no consequences
in the future, that's your call.

>
>
>>The hardest ones were the silent bugs without
>>crash dumps. Dumps where data is overwritten by other data? Hey,
>>that's a clue and much better than no clue at all. Unless you're
>>one of those software vendors who thinks that customers not being
>>able to prove that a bug exists is a good thing.
>
>
> If a bug is not detectable, then by what measure does the bug even
> exist?
>

Sorry. I meant the ones where the program does not behave as expected
but you have no concrete evidence of a problem. If the problem is
deterministiclly reproducable, you can use that fact to prove the
problem. Otherwise, you're out of luck.

--
Joe Seigh

When you get lemons, you make lemonade.
When you get hardware, you make software.

Le Chaud Lapin

unread,
Dec 29, 2006, 4:41:12ā€ÆPM12/29/06
to
Mirek Fidler wrote:

> Walter Bright wrote:
> > GC certainly is no panacea. But I've spent 25 years programming in C and
> > C++, and the worst, nastiest, most time consuming bugs by far have been
> > related to memory management. Memory management issues also consume a
> > large part of program design time.
>
> You must have been using completely different language than I did all
> that time. But the one I was using was named "C++" too. What is going
> wrong here?

I was wondering the same thing. The only time I think about memory
management is when I am designing the constructor and destructor of a
class, and the potential memory consumption of that class in a larger
system.

I am beginning to think that it is unjust to discuss the merits of GC
in C++ without first examining what goes on in the programmer's head
when designing software.

I know that if another electrical engineer suggested that all
MOSFET-based devices be wrapped in Faraday cages because it would be
easier for him to not thinking about overvoltage breakdown, he'd get
laughed out of the room.


-Le Chaud Lapin-

Dave Harris

unread,
Dec 29, 2006, 4:49:06ā€ÆPM12/29/06
to
jaibu...@gmail.com (Le Chaud Lapin) wrote (abridged):
> Every article related to .NET or C# that I have seen has had to do
> with
>
> 1. memory management
> 2. resource cleanup.

But garbage collection has almost nothing to do with resource cleanup. For
that you need lifetime modelling, and tools like destructors and operator
overloading. These tools are already in C++. Nobody is proposing to remove
them.

-- Dave Harris, Nottingham, UK.

Le Chaud Lapin

unread,
Dec 29, 2006, 4:43:17ā€ÆPM12/29/06
to
Mirek Fidler wrote:
> Actually, maybe the real problem of C++ future is that there is no big
> company behind it. No big company -> no hype -> big technically
> incompetent bosses go away...
>
> Alternative approach is to create "community" hype (think Python), but
> I am afraid C++ lost its moment long time ago (IMO, sometimes around
> the moment it was "boosted" by STL).
>
> Sad but true.

This is why the libraries need to be improved. I do not use Boost, but
I guess it is doing a good job.

As far as ensuring the longevity and integrity of C++, there is still
much opportunity, as Carlos Moreno hinted at. We could play the same
game that one "big company" plays. If killer applications were
developed in a way such that they had a strong affinity for C++, that
would help turn the tide in our favor. I could think of two such
applications today.

We have to remember, as big as the big company is, there are more of us
than there are of them. I certainly plan to do my part to protect C++.

-Le Chaud Lapin-

Andrei Alexandrescu (See Website For Email)

unread,
Dec 29, 2006, 4:49:51ā€ÆPM12/29/06
to
Carlos Moreno wrote:
> Badly managed pointer arithmetic, memory overwrite, buffer overflows,
> double-deletion, dereferencing invalid/uninitialized/deleted/NULL
> pointers, etc. etc. etc. are the *real* problems regarding memory
> management. GC has absolutely nothing to do with any of those.

I think this paragraph needs some major rethinking :o).

Andrei

Walter Bright

unread,
Dec 29, 2006, 6:28:58ā€ÆPM12/29/06
to
Carlos Moreno wrote:
> Walter Bright wrote:
>> GC certainly is no panacea. But I've spent 25 years programming in C and
>> C++, and the worst, nastiest, most time consuming bugs by far have been
>> related to memory management. Memory management issues also consume a
>> large part of program design time. These issues don't disappear with GC,
>> but they are 70-80% reduced with GC.
> I have to strongly disagree with these numbers; *memory management*
> problems tend to be nasty and hard-to-deal-with. But GC --- and
> correct me if I'm wrong --- only addresses memory leaks, which is
> by far, but really really really far, the least problematic of the
> categories of memory management issues.

It does far more than address memory leaks. It:

1) addresses dangling pointer bugs
2) removes the need to carefully keep track of who 'owns' a chunk of memory
3) (2) often results in a significant simplification of data structures
and algorithms
4) (2) often results in higher speed and less bloat because there's no
longer a need to increment/decrement counts or deal with exception and
thread safety on those counts
5) surprisingly, GC can often lead to a much reduced need to allocate
memory, because much more sharing of data can happen
6) makes it far easier to create reusable library code

> Badly managed pointer arithmetic, memory overwrite, buffer overflows,
> double-deletion, dereferencing invalid/uninitialized/deleted/NULL
> pointers, etc. etc. etc. are the *real* problems regarding memory
> management. GC has absolutely nothing to do with any of those.

It does because those problems crop up in code that tries to do explicit
memory management. For example, double deletion bugs are just as common
as failing to delete the memory at all.


> Memory leaks are relatively (actually, very) easy to find, and
> very easy to fix (provided an absolute minimum of sanity in the
> design and the coding);
> and, ironically (ironically from the
> point of view of wanting to add GC to C++), with C++ it is
> extremely easy to *prevent*.

No, they aren't, especially if you deal with 3rd party code. Of course,
if everyone was a top-drawer programmer, there wouldn't be any problems.
But we can't all fly with the eagles.

If it really is all so very easy, why has it taken so long to develop
shared_ptr<>? Are you sure your code has no leaks even in the presence
of exceptions thrown at awkward moments and other threads muck with your
reference counts?

I'll toss out another side effect of C++'s allegedly extremely easy
memory management - the lack of 3rd party libraries relative to those
available for GC'd languages. Reusable libraries for GC languages grow
like weeds, while libraries for C++ seem to require far, far more
engineering before they are generally reusable.


>> If there's a consistent problem area of programming, then that is a
>> fertile area for improving the language, since it is a pipe dream to try
>> and improve the programmer.
>
> I have to agree on this --- but you have to agree also (at least
> with the setiment) with Dijkstra's essay "How to Program When you
> Can't" (I probably misquoted the title).
>
> But putting that aside, I believe that GC is far from solving the
> memory management problems --- I firmly believe that the only
> contribution from GC would be increasing/promoting sloppiness
> and inviting increasingly lower-skilled programmers into the C++
> game. Is that what we want? Do we want to win the popularity
> contest? (because if we do, then accepting incomeptent and
> unskilled programmers into the game is an absolute necessity)

I have a little difficulty relating that sentiment to your earlier idea
that C++ memory management is "extremely easy."

As for the elitist sentiment you expressed, yes, you *do* want C++ to be
accessible to less than elite programmers. The reason is simple - they
pay the salaries of those who develop C++ compilers, tools, and
libraries. An elite language with too few customers is a dead language.

> If --- and I can not stress how much I'm saying this only for
> the sake of the argument --- Java is indeed a less error-prone
> and more effective/productive programming language, it would
> be due to the lack of pointer arithmetic (or rather, in a
> sense, the lack of pointers), and not for the GC.

The D programming language has pointers, and a GC (though you can also
do explicit memory management if you want to). The general experience
users have with that is an improvement in productivity and fewer bugs.

Kevin Hall

unread,
Dec 29, 2006, 6:28:35ā€ÆPM12/29/06
to
Le Chaud Lapin wrote:
> There is also the issue of libraries. STL is deficient. I could name
> 10-12 classes that are *absolutely fundamental* in systems engineering,
> and not only does C++ not have them, I don't know if anyone out there
> is even acknowledging that they do not exist. This is another reason
> for sloppy, operator new(), non-RAII type coding..the programmer is
> actually trying to create data structures that are fundamental, only we
> do not know of them yet.
OK, I'll bite. What are these dozen or so classes?

- Kevin

Walter Bright

unread,
Dec 29, 2006, 6:29:23ā€ÆPM12/29/06
to
Le Chaud Lapin wrote:
> There is also the issue of libraries. STL is deficient. I could name
> 10-12 classes that are *absolutely fundamental* in systems engineering,
> and not only does C++ not have them, I don't know if anyone out there
> is even acknowledging that they do not exist.

I'm very curious what these 12 are.

Andreas Huber

unread,
Dec 29, 2006, 6:30:09ā€ÆPM12/29/06
to
Le Chaud Lapin wrote:
[snip]

> "Uncovering and correcting memory issues in managed applications can
> be difficult. "

Agreed, but uncovering memory issues in unmanaged/un-GCed applications
is often even more difficult.

> I laugh a small bit each time I read this sentence. First, one of the
> biggest selling points of managed applications was GC. The other
> selling point, which was probably one of greatest marketing drugs in
> the 20th Century was "managed", giving the idea that it is somehow
> better than "unmanaged". So here we have that memory, managed, and
> difficult, are all be used in the same sentence, being written by the
> very organization that claimed to make these things not difficult.

Did they really claim "not difficult"? Where did you get that from? I've
only ever heard that things become easier.

> See again the problems:
>
> * An OutOfMemoryException is thrown.
> * The process is using too much memory for no obvious reason that
> you can determine.
> * It appears that garbage collection is not cleaning up objects
> fast enough.
> * The managed heap is overly fragmented.
> * The application is excessively using the CPU.
>
> Any engineer who designs a program that contains these problems in
> such significant quantities as to warrant an article being written
> about it should be ashamed of him/herself.

I fail to see how the above is relevant. A similar article could be
written about any language that offers manual dynamic memory management
(memory leaks, dangling pointers, etc.). As always, a fool with a tool
is still a fool. Ah, and don't get me started about memory fragmentation
problems in C++, but that's really beside the point.

I clarify my original question: Let's say you have a software written
twice, once in C++ and once in a GCed language (C#, Java). One and the
same engineer writes both systems who is proficient in memory management
in C++ (RAII, smart pointers, etc) and GCed languages. I believe the
engineer will typically spend considerably less time thinking about
memory management when building the system in the GCed language and
that's all that counts in terms of usability.

--
Andreas Huber

When replying by private email, please remove the words spam and trap
from the address shown in the header.

Stephen Howe

unread,
Dec 29, 2006, 6:30:53ā€ÆPM12/29/06
to

> You must understand, this is not some C++ lover/C# basher writing this.
> This is Microsoft writing about a language/framework for which they
> had 100% control over the design.
>
> "Uncovering and correcting memory issues in managed applications can be
> difficult. "
>
> I laugh a small bit each time I read this sentence.

Same here. Now I would not laugh if it worked out that GC really was a
success and memory mangement problems just faded into the background for
Microsoft. If that was the case, then adding GC as an optional component to
C++ would seem sensible.
But it seems to me that GC has not solved anything - it has just displaced
problems. The problem of reclaiming resources, the issues of whether
destructors are ever called and if so when, the issue of using destructors
and/or finalisers - it seems like a mess. The current C++ model with
guranteed destruction and RAII seems clean - do we really want complicate
the picture? Seems to me, we just need to educate newbie C++ programmers
over destructor discipline.

One of the arguments for adding GC to C++ is it eliminates the likelyhood of
certain types of newbie C++ programmer problems being made. A good argument.
But based on the Le Chaud Lapin's Microsoft URLs, that is clearly not the
case. So what arguments are left for adding optional GC? Certainly not
resource allocation and memory mangement simplicity.

Cheers

Stephen Howe

Le Chaud Lapin

unread,
Dec 29, 2006, 6:30:31ā€ÆPM12/29/06
to
Francis Glassborow wrote:
> No, only very few people that you currently know :-) Just as very few
> people wanted to use templates in 1989 :-) And even fewer people wanted
> to use metaprogramming during the 1990s. Until a facility is available
> it tends to be unwanted.

I agree that people can be resistant to change.

There is a difference here though. We could not have claimed in 1985
that we were intellectually familiar to the pro's and con's of
templates.

We can claim that we are intellectually familiar with garbage
collection, at least I can (in Lisp).

We are not operating from a position of ignorance here. We know what
GC is. We "feel' what it will do to C++. We don't want it.

We already have a mechanism to achieve virtue in system design that
obviates GC almost entirely, so much so that the few cases that we feel
it is appropriate, it could be done using mechanism of the existing
language.

-Le Chaud Lapin-


--

Le Chaud Lapin

unread,
Dec 29, 2006, 6:38:24ā€ÆPM12/29/06
to
Francis Glassborow wrote:
> Not quite, I am saying that efficient and safe multi-threaded
> programming will require exceptional skills in the future if it is done
> without GC. Manual memory management in a MT program either cripples
> modern hardware (by locking -- which is not cheap when that results in
> suspending 90% of your CPU power) or consumes an inordinate amount of
> highly skilled programmer time.

I disagree. Where do you see suspension of CPU power?

As far as the advanced skills, that has always been the case. Andrew
Tanenbaum was writing about multi-threading before some of us were
born. This has nothing to do with C++. You can get multi-threading
wrong in any language.

One could argue that the framework for multi-threading is
"undercooked." I would agree to this. But if that is the problem, in
irregular framework, then that is what we should fix.

I challenge the pro-GC people to demonstrate what they think is a
regular model for multi-threading.

-Le Chaud Lapin-


--

Mirek Fidler

unread,
Dec 29, 2006, 7:31:59ā€ÆPM12/29/06
to

Dave Harris wrote:
> jaibu...@gmail.com (Le Chaud Lapin) wrote (abridged):
> > Every article related to .NET or C# that I have seen has had to do
> > with
> >
> > 1. memory management
> > 2. resource cleanup.
>
> But garbage collection has almost nothing to do with resource cleanup. For
> that you need lifetime modelling, and tools like destructors and operator
> overloading. These tools are already in C++. Nobody is proposing to remove
> them.

Well, the main problem is that it is most likely impossible to couple
GC and destructors/constructors.

The real questionis: Should GC call destructors when sweeping objects?
Both answers to this question have serious pitfalls.

--
Mirek Fidler
U++ team leader. http://www.ultimatepp.org

Mirek Fidler

unread,
Dec 29, 2006, 7:31:31ā€ÆPM12/29/06
to

Le Chaud Lapin wrote:

> Mirek Fidler wrote:
> This is why the libraries need to be improved. I do not use Boost, but
> I guess it is doing a good job.
>
> As far as ensuring the longevity and integrity of C++, there is still
> much opportunity, as Carlos Moreno hinted at. We could play the same
> game that one "big company" plays. If killer applications were
> developed in a way such that they had a strong affinity for C++, that
> would help turn the tide in our favor. I could think of two such
> applications today.

Well, I think that the real problem in fact is STL direction... It
leads to complicated, over-engineered and hard to understand/maintain
code. But the problem is that STL feels oh so cool idea. In fact, STL
IS cool idea. But not every cool idea is suitable to do real job well.

Related to this thread and STL, I think it was really bad idea to add
container/algorithm library to object oriented language that is unable
to work directly with objects. No wonder that there are so many
requests for GC now...

--
Mirek Fidler
U++ team leader. http://www.ultimatepp.org

Nevin :-] Liber

unread,
Dec 29, 2006, 7:31:00ā€ÆPM12/29/06
to
In article <1167363058....@73g2000cwn.googlegroups.com>,
"Le Chaud Lapin" <jaibu...@gmail.com> wrote:

> See again the problems:

Let's compare them with the problems of using a regular malloc/free heap:

> * An OutOfMemoryException is thrown.

A std::bad_alloc exception is thrown.

> * The process is using too much memory for no obvious reason that
> you can determine.

The process is using too much memory for no obvious reason that you can
determine.

> * It appears that garbage collection is not cleaning up objects
> fast enough.

Nothing can clean up the objects.

> * The managed heap is overly fragmented.

The malloc/free heap is overly fragmented.

> * The application is excessively using the CPU.

The application is excessively using the CPU.


> Any engineer who designs a program that contains these problems in such
> significant quantities as to warrant an article being written about it
> should be ashamed of him/herself.

So you are basically arguing that we shouldn't be using a heap *at all*;
no polymorphism, all lifetimes have to be LIFO, etc.

>
> -Le Chaud Lapin-
>
> Reference:
>
> http://msdn.microsoft.com/msdnmag/issues/06/11/CLRInsideOut/default.aspx

--
Nevin ":-)" Liber <mailto:ne...@eviloverlord.com> 773 961-1620

Stephen Howe

unread,
Dec 29, 2006, 7:30:20ā€ÆPM12/29/06
to
> GC certainly is no panacea. But I've spent 25 years programming in C and
> C++, and the worst, nastiest, most time consuming bugs by far have been
> related to memory management.

I agree that they are bad but the amount of times that they have occured in
my code in 21 years has been very few, I can count on one hand. And these
days we have quite a few MM tools : Purify, Valgrind, BoundsChecker etc to
eliminate code errors.

> The D programming language's GC is written 100% in D.

Yes. And I like the fact that it is optional.
C++ should go the same route: optional

Stephen Howe


--

Walter Bright

unread,
Dec 29, 2006, 7:34:06ā€ÆPM12/29/06
to
Ion Gaztańaga wrote:
> That's not my case (I generally spend more time designing and fixing
> logic errors than fixing memory leaks) but couldn't this be fixed with
> an integrated leak detector? If C++ offers an standard leak detector
> for special debug builds (saying where and when was memory allocated
> and not freed, or reused after being freed) you can solve most of your
> problems and also detect logic errors (for example if calling delete[]
> frees more resources like sockets, files...). IBM/Rational Purify
> (garbage collection based, I think) is a good example for this
> (although it's very slow). żWill garbage collection will fix buffer
> overruns or access to uninitialized memory? If the main purpose is to
> avoid leaks, let's have a leak detector.

I've used leak detectors with C/C++ for 20+ years. The first generally
available (and still available) one is one I wrote and gave away 20
years ago: http://c.snippets.org/code/mem.txt They certainly help debug
memory allocation problems - but they don't make it any easier to
*design* robust memory management. They also don't guarantee correctness:

1) if you don't have a 100% comprehensive test suite
2) for every path an exception might take through your code
3) for threading issues
4) for code you have to work with that cannot be instrumented
5) for code you have to work with that uses different memory management
conventions

> If we also need some memory allocation with uncertain lifetime, let's
> have a garbage collected allocation method/pointer. But that's not the
> same as making the whole language (new/delete) garbage collected.

I'm not suggesting that C++ be made gc. There's too much water under
that bridge. What I'm doing is countering the false notions that GC is
only for the incompetent programmer, that correct explicit memory
management is easy, that GC has nothing to offer for elite programmers, etc.

P.S. I've implemented malloc and friends, malloc debuggers, multiple
garbage collectors, garbage collector debuggers, and more custom
allocators than I can recall.

Nevin :-] Liber

unread,
Dec 29, 2006, 7:33:27ā€ÆPM12/29/06
to
In article <1167208673....@h40g2000cwb.googlegroups.com>,

"Le Chaud Lapin" <jaibu...@gmail.com> wrote:

> The purpose of this post is to provide a bit of empirical evidence that
> GC is no panacea,

Other than as a straw man argument, I'm not really sure of folks who
think it is a panacea. Do you have references for this?

The usual thinking on GC is:

1. Garbage collection is a technique for managing memory.
2. Other resources should be managed by other means.


> http://msdn.microsoft.com/msdnmag/issues/06/08/nettingc/default.aspx
>
> The beginning of this article states:
> "A garbage-collected heap has deep ramifications for destructors, and
> that's where we'll start."

Well, not quite the beginning. You left out a few opening paragraphs,
including the sentence before the one you quoted:

"The second problem involves cleaning up resources other than memory
from the common language runtime (CLR) heap, which is garbage collected."

Trying to use garbage collection to manage resources other than memory
is difficult; this is not exactly news...

> http://msdn.microsoft.com/msdnmag/issues/06/11/CLRInsideOut/default.aspx
> All of these symptoms make me wary, but the second (*) is most
> impressive... "for no obvious reason that you can determine". The
> last word in this sentence, "determine", is closely related to another
> word, "determinism", a feature of C++ that is probably the basis for
> having never experienced any of these problems in C++.

You believe that most programs which use the malloc/free heap are
deterministic?

--
Nevin ":-)" Liber <mailto:ne...@eviloverlord.com> 773 961-1620

[ See http://www.gotw.ca/resources/clcm.htm for info about ]

Walter Bright

unread,
Dec 29, 2006, 7:32:57ā€ÆPM12/29/06
to
Le Chaud Lapin wrote:
> I was wondering the same thing. The only time I think about memory
> management is when I am designing the constructor and destructor of a
> class, and the potential memory consumption of that class in a larger
> system.

That's fine as long as you never have an object referred to by more than
exactly one reference.

Carlos Moreno

unread,
Dec 29, 2006, 7:41:04ā€ÆPM12/29/06
to
Andrei Alexandrescu (See Website For Email) wrote:
> Carlos Moreno wrote:
>
>> Badly managed pointer arithmetic, memory overwrite, buffer overflows,
>> double-deletion, dereferencing invalid/uninitialized/deleted/NULL
>> pointers, etc. etc. etc. are the *real* problems regarding memory
>> management. GC has absolutely nothing to do with any of those.
>
> I think this paragraph needs some major rethinking :o).

I would ask you to elaborate on that, please?

Ok, ok, I'm now noticing that double-delete would be addressed by
GC, as delete probably would disappear --- or at least its behaviour
would radically change. (somehow, I have the feeling that your
comment is a bit deeper than this detail)

After rethinking a little bit, I'm still really puzzled by how some
people --- putting aside whether it is fairly or unfairly --- talk
about the big mess/hell that C++ applications are concerning memory
management, as if the lack of GC was the obvious reason --- "with
gabage-collected languages, none of these happen", I can hear them
say! My point is, if with all instances of garbage-collected
languages that exist none of these problems happen, then it is
because of *other* features of those languages, and not because
of GC.

Carlos

Carlos Moreno

unread,
Dec 29, 2006, 9:59:30ā€ÆPM12/29/06
to
Walter Bright wrote:

>>> large part of program design time. These issues don't disappear with GC,
>>> but they are 70-80% reduced with GC.
>>
>> I have to strongly disagree with these numbers; *memory management*
>> problems tend to be nasty and hard-to-deal-with. But GC --- and
>> correct me if I'm wrong --- only addresses memory leaks, which is
>> by far, but really really really far, the least problematic of the
>> categories of memory management issues.
>
> It does far more than address memory leaks. It:
>
> 1) addresses dangling pointer bugs

How?? The way I see it, it only changes the behaviour in the presence
of accessing a dangling pointer --- worse: it is just hiding the
symptom of the real problem (the eral problem being that there *is*
a dangling pointer and someone is using it when they shouldn't).

IMHO, a better solution than GC is to make the behaviour of
dereferencing invalid pointers perfectly defined --- it really is
the infamous undefined behaviour the real cause of all the mess
that is attributed to memory management in C++. If dereferencing
an invalid pointer (*any form* of an invalid pointer --- deleted,
uninitialized, NULL, etc.) threw an exception, things would be
much, much better.

Again, we do not want to promote sloppiness from the prorgammers;
hiding the symptoms of a problem and make it silently have no
effect (or seem to have to effect) does not help; it promotes
and fascilitates sloppiness.

> 2) removes the need to carefully keep track of who 'owns' a chunk of
memory

The compiler is very careful in keeping track of who owns what;
and we already have the tools to leverage all this compiler power
to automate memory management and relieve the programmer from the
big nightmare.

> 3) (2) often results in a significant simplification of data structures
> and algorithms

I disagree. Well, or rather, I could claim that it is far more
often that the "automatable" model of C++ memory management results
in a simplification of data structures and algorithms.

> 4) (2) often results in higher speed and less bloat because there's no
> longer a need to increment/decrement counts or deal with exception and
> thread safety on those counts

Higher speed and less bloat??? It depends on how you define higher
speed and how you define bloat --- I could claim that GC is an
unnecessary bloating of my apps; and as for speed; if I unpredictably
have to wait who-knows-how-long because the garbage collector decided
that it needed/wanted to act, I do not think that would qualify as
"good speed" --- or, you could put it this way: you want speed? I
need responsiveness. Speed, we have it almost for free nowadays
with ever increasingly powerful hardware.

> 5) surprisingly, GC can often lead to a much reduced need to allocate
> memory, because much more sharing of data can happen

Ok, good point. But again, in C++ you can already achieve the exact
same level of data sharing, with pointers and without worrying about
all the messy details of manual memory management (shared_ptr when
you need it, custom data structures when you must)

> 6) makes it far easier to create reusable library code

Maybe. Only, and with much stress, *maybe* ... But my opinion
keeps being that the only thing to be blamed in here is that far
too many C++ libraries are really written in C (well, maybe
that's changing, and quite likely that's not true for high-
quality libraries). But I'm soooo sooooo really fed up with
libraries that deal with strings and only accept and return
char pointers!!

> As for the elitist sentiment you expressed, yes, you *do* want C++ to be
> accessible to less than elite programmers.

And it is my firm opinion that it is --- I have been teaching for
several years now a web programming course in which the students,
who typically and in average are *far* below elite top-of-the-line
C++/software developers, create really nice applications; the
students never get to hear the word pointer, except for some
compiler errors or warnings (that often call for my assistance
to help them understand and often also to fix the problem).

I would really be willing to bet one month of my salary that none
of any applications that any of my students (in that course) has
ever created has any memory leaks, or any memory-management problem
whatsoever; and we're talking about a lot of them (and as I said,
most of them are far below "elitesque" level). Actually, wait,
maybe some of them do have problems --- I'm now remembering that
a few of those students had had prior experience programming in
C; yep, I would bet another month of my salary that if there
are any programs with memory management issues, is one created
by some of those students with prior experience in C (well, or
in C++, which they most likely had learned from the likes of
Deitel & Deitel, which means that they had really learned C)

Carlos
--

Le Chaud Lapin

unread,
Dec 29, 2006, 10:01:32ā€ÆPM12/29/06
to

Nevin :-] Liber wrote:
> In article <1167363058....@73g2000cwn.googlegroups.com>,
> "Le Chaud Lapin" <jaibu...@gmail.com> wrote:

[snipped nice rebuttal]

> So you are basically arguing that we shouldn't be using a heap *at all*;
> no polymorphism, all lifetimes have to be LIFO, etc.

No, I am saying that there is no silver-bullet.

I am saying that a mess is a mess under both models.

We should not succumb to the illusion that GC will enhance the
effectiveness of those who are already predisposed to lack of
discipline. It will only encourage them to make even bigger messes,
which would be fine by me, as long as they do it in a language other
than C++.

-Le Chaud Lapin-


--

Le Chaud Lapin

unread,
Dec 29, 2006, 10:00:57ā€ÆPM12/29/06
to

Walter Bright wrote:
> Le Chaud Lapin wrote:
> > I was wondering the same thing. The only time I think about memory
> > management is when I am designing the constructor and destructor of a
> > class, and the potential memory consumption of that class in a larger
> > system.
>
> That's fine as long as you never have an object referred to by more than
> exactly one reference.


And how often does that happen? If it is happening all the time, you
are not doing something right.

This why I keep saying in probably 20% of my posts, the problem has to
do with what goes on in the engineers head when he builds his system.

It should be evident that there are gross disparities in intellectual
process between those who like GC and those who don't. Note that I
said "like". I readily acknowledge that there are others in this group
who do not necessarily like or dislike GC, but regard it as a novelty
that might or might not have beneficial/detrimental effects on C++.

I think what is happening is that some people using C++ simply never
learned how to build large, scalable systems. I have no doubt that is
such people where to try to "engineer" systems in electronics the same
way they do in software, they would get never get a product out the
door. The first time someone from the old guard comes sees all the fat
and slop in the circuit, it will get tossed.

It is my belief that the most significant problem in "software
engineering" today is that many of the so-called software engineers are
not really engineers at all, but coders who are highly-paid, generously
pampered, and more than willing to meandering to the maze of complexity
until the blue box on the screen is in just the right place and the
program does not crash and over a two week period it only leads "a tiny
bit of memory." The most recent example of such an individual is
someone who works for a large anti-virus company that sells their
products in a black and yellow box. His salary is around $160,000/US
per year, his title is Architect, and he could not write "Hello,
World." in BASIC. That is an extreme example, but the people just
beneath him who do know how to write code are not much better, not for
the work they have been entrusted with. One of them, actually said to
me, "I don't really like all that data structures stuff, I just like to
get things done."

It should come as no surprise that the richest man in the world made
his fortune in software the impunity of making something of low-quality
and still getting paid for it is unprecedented. I cannot think of any
other engineering discipline where this mentality would be tolerated.

-Le Chaud Lapin-

Ion GaztaƱaga

unread,
Dec 29, 2006, 10:02:26ā€ÆPM12/29/06
to
> I've used leak detectors with C/C++ for 20+ years. The first generally
> available (and still available) one is one I wrote and gave away 20
> years ago: http://c.snippets.org/code/mem.txt They certainly help debug
> memory allocation problems - but they don't make it any easier to
> *design* robust memory management. They also don't guarantee correctness:
>
> 1) if you don't have a 100% comprehensive test suite
> 2) for every path an exception might take through your code
> 3) for threading issues
> 4) for code you have to work with that cannot be instrumented
> 5) for code you have to work with that uses different memory management
> conventions

1) and 2) are not very convincing for me, because RAII its in our
hands. Of course, I can make mistakes, but if instead of using char[],
I use std::string, I'm pretty sure that no memory will be leaked even
every single statement of my function throws an exception. But I
understand your points.

> If we also need some memory allocation with uncertain lifetime, let's
> > have a garbage collected allocation method/pointer. But that's not the
> > same as making the whole language (new/delete) garbage collected.
>
> I'm not suggesting that C++ be made gc. There's too much water under
> that bridge. What I'm doing is countering the false notions that GC is
> only for the incompetent programmer, that correct explicit memory
> management is easy, that GC has nothing to offer for elite programmers,
etc.

I don't think GC is for incompetents, but I do think that incompetents
use too much GC.

If you have memory that you don't know when it will be freed, it's
clear that GC is a good option. C++ should definitely have it. But I do
think that most memory allocations have an easy, single owner lifetime,
and that can be easily managed using constructors and destructors (or
even better, with a member auto_ptr/unique_ptr<>). The single ownership
can be efficiently transferred through unique_ptr<>.

For shared ownership, if we need to deterministically free resources
(for example, when all the users of a net connection end their job we
want to close the connection) shared_ptr<> is a good option, because
the destructor will be called when the last reference dies.

For memory with uncertain or too complicated lifetime, GC is the right
option. The problem is that, IMHO, making GC the default choice is not
a good option. Although in theory GC *can* improve memory use, I think
most of the problems with GC have relationship with a) finalization b)
excessive memory use. And that's maybe because garbage collection is
being used for tasks that are more efficiently (without any effort,
like using unique_ptr/auto_ptr in single owner memory) handled with
manual management.

My experience is that both Java and Managed C++ desktop applications
consume much more memory than their previous C++ incarnations. I'm not
talking about old applications or environments and I'm not the only one
with this feeling. But of course, this is only an impression and it's
not a fact.

My fear is not related with adding GC to C++ but with *how* it will be
added. And which are the implications of "optional". For the moment, I
can only see one proposal, and IMHO that proposal can silently break my
old code, because my code was based in deterministic resource
liberation and manual management. I would prefer a C++/CLI-like
approach, because it's less intrusive and because creating a garbage
collector that can eat pointer xor-ing, pointer operations like < or
==, and storing pointers inside any memory type, does not seem an easy
task without paying some performance price (I'm not an expert, so don't
take this statement too seriously).

How I am supposed to write a generic code that can be used in
environments both without GC (I must explicitly call delete[]) and with
GC (no deterministic finalization, must call dispose manually) ? Should
I write two control paths checking std::is_garbage_collected() at
runtime?

> P.S. I've implemented malloc and friends, malloc debuggers, multiple
> garbage collectors, garbage collector debuggers, and more custom
> allocators than I can recall.

I'm pretty sure you know a lot more than me about this issue (and in
general about C++). After all, you have written C++ compilers, created
D language and its library... something that a tiny fraction of C++
developers is capable to do, no doubt.

So, based on your experience, do you think that transparent garbage
collection (N2128, new/delete garbage collected, scanning for pointers
in integers if the class is not gc_strict, operator < and == with
pointers, using pointers as hash keys...) can have performance issues
or algorithm limitations comparing to a C++/CLI-like approach (a
different pointer type, the compiler forbids castings on those
pointers...)?

There is no C++ finalization proposal yet AFAIK, and I think that
having GC without solving finalization is not desirable. Which is, in
your opinion, the best way to deal with finalization issues that have
arisen in other languages (Java problems, for example, are mentioned
N2128)?

Regards,

Ion

Le Chaud Lapin

unread,
Dec 29, 2006, 10:00:00ā€ÆPM12/29/06
to
Andreas Huber wrote:
> Did they really claim "not difficult"? Where did you get that from? I've
> only ever heard that things become easier.

Microsoft Writes:
"Last month, I described the motivation for garbage-collected
environments: to simplify memory management for the developer."
http://msdn.microsoft.com/msdnmag/issues/1200/GCI2

'.NET 2.0 For Delphi Developers' writes:
"At the same time, .NET offers garbage collection that frees us from
memory management overhead."
http://www.midnightbeach.com/.net/


'Sams Teach Yourself Visual C++. .NET in 24 Hours' writes:
Using Managed Code for Easy Memory Management
http://safari5.bvdep.com/0672323230/ch05lev1sec2"

While looking for references, I found this statement about Java. Why
am I not suprised:
"Although Garbage Collection (GC) in Java attempts to simplify memory
management by relieving the developer from allocating, tracking and
freeing memory, it still cannot totally eliminate memory leaks. Objects
may be inadvertently kept beyond their useful lives, or may be
referenced so that GC will not scoop them up. Detecting memory leaks,
and finding and eliminating their root causes, are crucial steps in
improving the performance of a Java application."
http://websphere.sys-con.com/read/258406.htm

> > Any engineer who designs a program that contains these problems in
> > such significant quantities as to warrant an article being written
> > about it should be ashamed of him/herself.
>
> I fail to see how the above is relevant. A similar article could be
> written about any language that offers manual dynamic memory management
> (memory leaks, dangling pointers, etc.). As always, a fool with a tool
> is still a fool. Ah, and don't get me started about memory fragmentation
> problems in C++, but that's really beside the point.

But in this case the fools are trying to deposit their fools' gold in
our bank because their bank went bankrupt.

C++ is what it is. We stated that, if you are an engineer who knows
how to build systems (in any engineering disciplines), and you are in
tune with the mechanics of RAII constructor/destructor call sequence,
then you should not have many problems with memory management. We did
not claim more. We never said you could call new/delete willy-nilly
and magic would happen. What you see is what you get.

The GC people are saying that, if you use GC, it relieves you from
having to think about memory management. This is a lie. That
Microsoft is writing so many articles about how to "properly" do memory
management under .NET is plain evidence of this fact.

The problem is that, though this lie is beginning to reveal itself in
other languages, that doesn't seem to stop people from trying to
reinvent it in the context of C++.

The truth is that memory management is complex for any beginner. The
only real hope for "proper" memory management is to engineer the
system appropriately.

> I clarify my original question: Let's say you have a software written
> twice, once in C++ and once in a GCed language (C#, Java). One and the
> same engineer writes both systems who is proficient in memory management
> in C++ (RAII, smart pointers, etc) and GCed languages. I believe the
> engineer will typically spend considerably less time thinking about
> memory management when building the system in the GCed language and
> that's all that counts in terms of usability.

I disagree. I have no experience in C# and not much in Java, but I
have used Lisp/Scheme much, and of course, C++. I don't think about
memory management too much in C++, so C# would automatically lose. I
spend most of my time thinking about

1. data structures and algorithms
2. clean interfaces so that users of my class will feel good when they
use them

Memory management is not on this list. I have used the
constructor/destructor model so many times, when I go to write
Foo::~Foo(), I am almost disappointed, as there is not much to think
about: get write of whatever memory was allocated in the constructor.
As far as usability goes, as I stated earlier, I get more questions
from programmers who switch to C#/.NET asking me to help them fix their
memory management issues (over the Internet) than I ever got for C++.
I also used to receive C++ questions also, but I can honestly say that
the C# code is typically so sprawling and unwieldy that the best I can
tell them is to get a box with more RAM.

I also think you should read the articles that are being written by
Microsoft and ask yourself, honestly, what is the real difference
between intellectual capacities to understand

1. C++ constructor(new)/destructor(delete)

versus

2. C# special cases of finalize, dispose,

-Le Chaud Lapin-


--

Edward Diener No Spam

unread,
Dec 29, 2006, 10:00:34ā€ÆPM12/29/06
to
Andreas Huber wrote:
> Le Chaud Lapin wrote:
>> Any engineer who designs a program that contains these problems in
>> such significant quantities as to warrant an article being written
>> about it should be ashamed of him/herself.
>
> I fail to see how the above is relevant. A similar article could be
> written about any language that offers manual dynamic memory management
> (memory leaks, dangling pointers, etc.). As always, a fool with a tool
> is still a fool. Ah, and don't get me started about memory fragmentation
> problems in C++, but that's really beside the point.
>
> I clarify my original question: Let's say you have a software written
> twice, once in C++ and once in a GCed language (C#, Java). One and the
> same engineer writes both systems who is proficient in memory management
> in C++ (RAII, smart pointers, etc) and GCed languages. I believe the
> engineer will typically spend considerably less time thinking about
> memory management when building the system in the GCed language and
> that's all that counts in terms of usability.

There are two situations which can occur, one for each side. If there
are many non-memory resources which occur, the GCed language programmer
will probably have more to consider. If there are cross-referenced
dynamically allocated objects which occur, the non-GCed C++ programmer
will probably have more to consider. I am of course assuming that the
non-GCed C++ programmer knows about standard library containers as well
as how and when to use C++ smart pointers such as std::auto_ptr,
boost::shared_ptr, boost::scoped_ptr, and boost::weak_ptr. Of course you
may say that having to know about the latter concepts means that the
non-GCed C++ programmer has more to consider because he must understand
more things about automatically dealing with memory management issues in
modern C++. I would then counter with my opinion that resource
management issues show up far more times in general programming than
cross-referenced objects do.

The OP posted an extreme argument against GC, and a responder posted an
extreme argument against C++ memory management. As usual a reasonable
understanding of the strengths and weaknesses of both lie somewhere in
the middle. But it is endlessly amusing to read how extremists on both
sides argue and demand their own point of view as the only way to think,
with one side guarding the purity of current C++ resource management (
for the sake of C++ and everyone's benefit of course <g> ) against the
intrusion of even an optional GC invader, and the other side arguing
that C++ is endlessly deficient in the memory management area and must (
for the sake of C++ and everyone's benefit of course <g><g> ) be
improved by a GC system in order to ensure its survival.

--

Le Chaud Lapin

unread,
Dec 29, 2006, 10:03:04ā€ÆPM12/29/06
to

Andrei Alexandrescu (See Website For Email) wrote:
> Carlos Moreno wrote:
> > Badly managed pointer arithmetic, memory overwrite, buffer overflows,
> > double-deletion, dereferencing invalid/uninitialized/deleted/NULL
> > pointers, etc. etc. etc. are the *real* problems regarding memory
> > management. GC has absolutely nothing to do with any of those.
>
> I think this paragraph needs some major rethinking :o).
>

What needs rethinking is the process by which the programmers get
themselves this mess in the first place.

-Le Chaud Lapin-

Le Chaud Lapin

unread,
Dec 29, 2006, 10:01:55ā€ÆPM12/29/06
to
Kevin Hall wrote:
> Le Chaud Lapin wrote:
> > There is also the issue of libraries. STL is deficient. I could name
> > 10-12 classes that are *absolutely fundamental* in systems engineering,
> > and not only does C++ not have them, I don't know if anyone out there
> > is even acknowledging that they do not exist. This is another reason
> > for sloppy, operator new(), non-RAII type coding..the programmer is
> > actually trying to create data structures that are fundamental, only we
> > do not know of them yet.
> OK, I'll bite. What are these dozen or so classes?

Most of them are related to distributed communication:

1. Integer (needed for asymmetric crypto) MJ Kronenburg is doing this
right.
2. Monarchy<> (what you would call a single-rooted tree)
3. Polyarchy<> (what you wold call a multi-rooted tree)
4. Thread::Object (can't say much, but there *is* a regular model for
multi-threading)
5. Instant, Duration (Boost appropriated good library for doing this)
6. Associative X, where X is any of those in #2 or #3
7. Prioritized X, where X is #6, #2, #3 (not priority queue, Dijkstra's
Algo needs more)
8. Nonce<> (easy to make, very useful to have)
9. String Translator (Spirit of Boost might be related to this)
10. String Parser (Spirity of Boost might be related to this)
11. Various set-based algorithms (AVL, Splay, Binary Regular, Binary
Optimum, Red-Black)
12. Compressors of various sorts (LZ, etc)
13. Ciphers of various sorts (but done cleanly, without too many
assumptions)
14. Synchro primitives (timer, mutex, event, semaphore, etc.)

Notice that there is nothing on this list that has to do with GUI
development. This is a tragedy. Novice programmers often fail to
appreciate the distinction between C++ proper and the library
associated with it. If there is no GUI library, then, as far as they
are concerned, C++ lacks support for GUI development. Those with the
initiative to ask about the state of the art of GUI development on
Windows only to learn that it is MFC will become even more convinced
that C++ is a nasty language for software development.

As Carlos Moreno pointed out, a lot of these misconceptions can be
ameliorated by simply boosting (pun intended) the C++
libraries...BUT...you cannot simply concoct something and expect people
to use it just because it works without crashing. Care must be taken
so that, when these novice programmers use C++, the experience is
enjoyable. Form is key. Microsoft cheated a bit in this regard. They
gave us a baboon's butt (MFC) for C++, but when it was time to make a
GUI for their own language, C#, they cleaned things up considerably,
thus reinforcing the erroneous perception that C++ is inferior to C#.

-Le Chaud Lapin-

Le Chaud Lapin

unread,
Dec 29, 2006, 10:07:28ā€ÆPM12/29/06
to

Walter Bright wrote:
> 1) if you don't have a 100% comprehensive test suite
> 2) for every path an exception might take through your code
> 3) for threading issues
> 4) for code you have to work with that cannot be instrumented
> 5) for code you have to work with that uses different memory management
> conventions

I never have to deal with 1-3. I have a massive system (in terms of
scope, not lines of code) where am 100% certain that there are no
memory leaks. Anywhere. This is the true power of RAII. It allows
tuckability - you can make something, tuck it way, and be ready to bet
your left arm that there is nothing wrong with it in terms of memory
issues. You cannot have the same confidence with sloppy engineering,
which, IMO, is *most* of the impetus for wanting GC.

> I'm not suggesting that C++ be made gc. There's too much water under
> that bridge. What I'm doing is countering the false notions that GC is
> only for the incompetent programmer, that correct explicit memory
> management is easy, that GC has nothing to offer for elite programmers,
etc.

We are saying that C# people who complain that GC did not live up to
its promise are examples of the former type of programmer. As for the
elite programmers, if they want GC, one has to examine the situation.
I can think of two possibilities:

1. You are designing at system that has an inherent need for GC
2. You are ignoring that which C++ gives you, RAII and related
principles.

Again, it is our opinion that those who think they need GC on a
day-to-day basis, in general, are probably engineering systems poorly.
Anyone who has ever taught at the university level sees this phenomenon
in students - sometimes you have to structure the problems in such a
way to force the students to face that which they would really rather
not. I would recommend to the pro-GC people who would expect it to use
it in ordinary development to try to go for a full week (month) without
using operator new() or operator delete().

> P.S. I've implemented malloc and friends, malloc debuggers, multiple
> garbage collectors, garbage collector debuggers, and more custom
> allocators than I can recall.

Based on your web site, I believe it. Your experience could be
valuable in explaining to the .NET crowd why GC is not meeting their
expectations.

-Le Chaud Lapin-

Mirek Fidler

unread,
Dec 30, 2006, 11:28:53ā€ÆAM12/30/06
to

Walter Bright wrote:
> Le Chaud Lapin wrote:
> > I was wondering the same thing. The only time I think about memory
> > management is when I am designing the constructor and destructor of a
> > class, and the potential memory consumption of that class in a larger
> > system.
>
> That's fine as long as you never have an object referred to by more than
> exactly one reference.

More correct is to say object *owned* by two or more references.

In my code, there is always some scope that object belongs. It can be
referred in the same scope or nested scopes by pointers. Pointers
*never* own the object except implementation details of e.g.
containers. "shared ownership" is bad practice and shared_ptr
exceptionally bad idea IMHO.

And yes, I am well aware there is danger of dangling pointers and I
agree that is something GC can help with. But danger is not high, as
long as you keep "pointers only in the same or nested scope" rule. For
rare cases you need more, there is special smart pointer that gets
nullified when pointee is destroyed.

Kevin Hall

unread,
Dec 30, 2006, 11:25:47ā€ÆAM12/30/06
to

(1) A large-integer (variable-bit) class would be nice. I'd also like
to have a large fixed-bit template class become standard.

(2)(3) I'm sorry, I'm not even remotely familiar with either of these
concepts. Could you point me someplace where I could learn more?
(6)(7) Since these depend on (2) and (3), I'm lost here too.

(4)(14) Threading isn't even part of C++. And it is admittedly very
difficult to figure out how to incorporate threading into a language
with as broad a base as C++. Take semaphores for example. Should C++
use System V semaphores? Posix-style semaphores? Un-named or named
semaphores? Should C++ specify whether semaphores should be process
local or cross-process semaphores? (Linux kernel 2.4 didn't even
support named and cross-process semaphores. Thankfully Linux kernel
does now.) The point is that as soon as C++ defines the types of
synchronization primitives, then C++ cannot be fully implemented on
many OSes. :-(

(5) What are the 'Instant' and 'Duration' classes? Do you mean a
timestamp object and a time difference class that effectively wraps the
functions in <ctime>?

(8) I've never had the need for a Nonce class. A simple google search
showed me there are many different ways to implement a nonce and that a
single template would likely not be sufficient. But I'm naive on the
topic. Maybe there is a universal way a template nonce could be
implemented. But I'm not really sure a Nonce class is really that
fundamental.

(9) What do you mean string translator? Certainly you don't mean an
English-to-Arabic translator class! Do you mean ASCII to UTF-16 class?
The standards comittee is encouraging UTF proposals, so we may have
something in C++1x (since it doesn't seem likely we'll see anything in
C++0x).

(11) Set algorithms or set types? If you mean set types, then I'd say
C++ has historically abstained from implementation details -- thus
std::set. If you mean set algorithms, then I'd say that since C++ has
abstained from specifying the types of trees to be used, then it is
difficult to specify the types of algorithms to be used on those types.

(12) A compression framework would be nice, however specific
compression algorithms would be difficult to specify. The only one
that seems that could be reasonably part of the current standard is
ZIP. I think LZ was pattent protected until very recently. 7-ZIP and
RAR are too recent (and RAR is still pattent protected). Anyway, the
problem I see with compression algorithms is very similar to the
problem I see with standardizing GUI libraries: the details change too
quickly. 7-ZIP, RAR, and XP-style GUIs are what are used today. But
tomorrow we'll have new archive formats and Vista graphics. Speaking
of GUI frameworks, I' like to note that C# nor the CLR/CLI define a
graphics framework -- Windows Forms are part of MS's .NET libraries and
not part of the C# language or associated standards. Java is the only
really popular language that I know of that has standardized GUIs and I
don't think that standard Java is going to offer anything to really
take advantage of Vista graphics features (or OS-X graphics features or
DirectX or ...).

(13) A genereal cipher framework would be nice too, but specific
ciphers would likely have similar problems as compression algorithms
and GUI frameworks -- they would be out-of-date by the next standard.

Le Chaud Lapin wrote:
> There is also the issue of libraries. STL is deficient. I could name
> 10-12 classes that are *absolutely fundamental* in systems engineering

I'm pretty sure I would qualify as a systems engineer and even if I
didn't, I'm pretty sure my company would qualify as a "systems
engineering shop" (see next paragraph for what I believe are
qualifications). Anyway, the only feature you mention that is
*absolutely fundamental* to the work we do relates to threading. And
here we have tried our best to provide an abstraction layer for things
like semaphores, timers, and events -- but we have come across problems
with differnt OSes where things could not be implemented fully -- Linux
kernel 2.4 being the worst example. I don't see how C++ can require
compiler vendors to provide much more than atomic operations -- and
even here, not all processors where C++ is currently supported support
atomic operations. But the good news is that the ISO C++ comittee is
actively researching what can be specified for threading.

(I work for a motion control company that creates our own hardware,
uses FPGAs and creates our own FPGA images, creates our own embedded
software (for DSP chips, PPC processors), our own libraries for our
customers to use (for various real-time and non-real-time OSes), and
our own Windows utilities, with some even written in .NET. Safety is
absolutely critical since we deal with many medical applications. And
we very frequently work side-by-side with our customers to help ensure
the soundness of the entire machine from the software all the way down
to the mechanical and electrical systems. As far as I know, this
qualifies as "systems engineering". And I have worked with all of
these areas with the exception of the hardware and FPGA design --
though I've had to be intimately familliar with certain aspects of
both.)

- Kevin Hall

Andrei Alexandrescu (See Website For Email)

unread,
Dec 30, 2006, 11:27:28ā€ÆAM12/30/06
to
Nemanja Trifunovic wrote:
> Francis Glassborow wrote:
>> In article <1167258570.5...@79g2000cws.googlegroups.com>,
>> Nemanja Trifunovic <ntrif...@hotmail.com> writes

>>> Le Chaud Lapin wrote:
>>>> The purpose of this post is to provide a bit of empirical evidence that
>>>> GC is no panacea, and that adding it to C++ might do more harm than
>>>> good.
>>> I agree with most of the points from your post, but there is nothing to
>>> worry about: C++ is not and will *never* be a garbage-collected
>>> language. It is possible that we see optional garbage collection added
>>> to the language, but I doubt even that will happen.
>> I would lay heavy odds that you are mistaken. Mandatory optional GC
>> (i.e. compilers are required to provide it if the programmer wants it)
>> is almost certain to be part of any multi-threading option and if the
>> next version of C++ does not have explicit support for efficient
>> multi-threading on multi-core processors it will be a dying language.
>>
>
> So you are saying efficient multithreading is not possible without GC?

It is. It's just much harder - much more harder than manual memory
management.

Andrei

Le Chaud Lapin

unread,
Dec 30, 2006, 11:25:11ā€ÆAM12/30/06
to
Nevin :-] Liber wrote:
> You believe that most programs which use the malloc/free heap are
> deterministic?

Finally we get to the fundamental issue. :) I believe they are not,
but should be.

Like Mirek Fidler, I rely heavily on the "automatic" features of C++.
These are:

1. Put operator new() in the constructor
2. Put operator delete() in the destructor
3. Never use a polymorphic object when a monomorphic object will do.
4. Never new() an automatic object just for the hell of it. That's
what auto is for.
5. If a massive structure is required, built it using containers.
Containers are lovely.

I will give you a concrete example:

In one of my EXE's, I have a data structure which you would call a
multi-rooted tree. The tree is associative, so I can look up a
node-pair in the tree based on List<> of elements. The elements in the
list successively help to locate the pair based on the left-hand
element of each pair. The type of the LHE of a pair is the same as
the type of an element of the List<>. The structure is templated so
that all types are polymorphic at compile time. In my current system,
the RHE of a node in the tree is itself a *massive* data structure
containing no less than 4 associative sets, 2 associative list, a
hybrid structure that is essentially a List<String,
Red_Black::Associative_Set<String, List<String> ...."'. This RHE also
contains Integers that can be 400 digits long, as well as primitives
for cryptography, time-related objects, etc.

If someone were to ask me if this massive thing would ever leak memory,
I'd say "no" before they could finish the sentence. How do I know? I
know because the system has been structure in a way that memory leakage
is impossible. The worst that can happen is an exception could be
thrown for lack of memory for call to new().

But that's not the fun part. What makes this fun is that this massive
structure is one of more than 25, in the same program, with up to 30
hreads at once, all with locking and unlocking on structures, seeking
to various elements, doing database I/O as well as over network I/O.
There are maybe 225 .cpp files , and the number of lines of code that
contains a new() or a delete is less than 15, probably more like 10.
What is nice about this situation is that the few times that I *do* use
new() or delete, I know with certainty that the nature of the data
structure being modeled is such that it absolutely, positively,
warrants a polymorphic object. So I have no problems with it, and I
can easily eyeball the situation and say again.."This system will not
leak memory. Ever."

This is where we differ. Some people got it in their head that, since
it is hard to "find the classes", they might as well go for broke and
make everything a giant new/delete/polymorphic slop party. They take a
moderately complex data structure that could have easily been
monomorphic and make it polymorphic...and deal with the consequences.

-Le Chaud Lapin-


--

Andrei Alexandrescu (See Website For Email)

unread,
Dec 30, 2006, 11:29:22ā€ÆAM12/30/06
to
Carlos Moreno wrote:
> Andrei Alexandrescu (See Website For Email) wrote:
>> Carlos Moreno wrote:
>>
>>> Badly managed pointer arithmetic, memory overwrite, buffer overflows,
>>> double-deletion, dereferencing invalid/uninitialized/deleted/NULL
>>> pointers, etc. etc. etc. are the *real* problems regarding memory
>>> management. GC has absolutely nothing to do with any of those.
>>
>> I think this paragraph needs some major rethinking :o).
>
> I would ask you to elaborate on that, please?
>
> Ok, ok, I'm now noticing that double-delete would be addressed by
> GC, as delete probably would disappear --- or at least its behaviour
> would radically change. (somehow, I have the feeling that your
> comment is a bit deeper than this detail)

Memory overwrite is a consequence of unsoundness. As I've shown in the
past, garbage collection is a prerequisite for soundness. It is a common
mistake of practitioners to think that GC is to babysit lousy
programmers. The reality is that GC came about, and always is, a tool
for improving soundness (memory safety) of programs.

Buffer overflows often occur because programmers don't want to
dynamically allocate memory due to the headache of managing it.

Double deletion... all clear.

Dereferencing invalid/uninitialized/deleted/NULL pointers - that happens
when the program is unsound. GC either reduces that or makes it
impossible. NULL pointers are a case in which the OS can help to some
extent.

Probably the purpose of GC is the largest misunderstanding of research
work in the industry.


Andrei

Walter Bright

unread,
Dec 30, 2006, 11:35:18ā€ÆAM12/30/06
to
Le Chaud Lapin wrote:
> Walter Bright wrote:
>> Le Chaud Lapin wrote:
>>> I was wondering the same thing. The only time I think about memory
>>> management is when I am designing the constructor and destructor of a
>>> class, and the potential memory consumption of that class in a larger
>>> system.
>> That's fine as long as you never have an object referred to by more than
>> exactly one reference.
> And how often does that happen? If it is happening all the time, you
> are not doing something right.

It happens all the time for me. But I remain unapologetic. I think
you've made an extraordinary claim that such designs are wrong. And
certainly, *not* using such designs would be unusual practice for C++.

> This why I keep saying in probably 20% of my posts, the problem has to
> do with what goes on in the engineers head when he builds his system.
>
> It should be evident that there are gross disparities in intellectual
> process between those who like GC and those who don't. Note that I
> said "like". I readily acknowledge that there are others in this group
> who do not necessarily like or dislike GC, but regard it as a novelty
> that might or might not have beneficial/detrimental effects on C++.

I programmed for decades before I was forced to use a GC (you know how
it is when someone else is paying your bills!). During that time, I
assumed that GC was for incompetent wussy programmers. After studying
GCs, implementing them, and using them, I've changed my mind quite a bit.

> I think what is happening is that some people using C++ simply never
> learned how to build large, scalable systems. I have no doubt that is
> such people where to try to "engineer" systems in electronics the same
> way they do in software, they would get never get a product out the
> door. The first time someone from the old guard comes sees all the fat
> and slop in the circuit, it will get tossed.

A lot of my attitudes about programming come from experience early in my
career when I worked on (mechanical and hydraulic) flight controls
design for the 757 airliner. There's a lot that software developers can
learn from such, and vice versa.

> It is my belief that the most significant problem in "software
> engineering" today is that many of the so-called software engineers are
> not really engineers at all, but coders who are highly-paid, generously
> pampered, and more than willing to meandering to the maze of complexity
> until the blue box on the screen is in just the right place and the
> program does not crash and over a two week period it only leads "a tiny
> bit of memory." The most recent example of such an individual is
> someone who works for a large anti-virus company that sells their
> products in a black and yellow box. His salary is around $160,000/US
> per year, his title is Architect, and he could not write "Hello,
> World." in BASIC. That is an extreme example, but the people just
> beneath him who do know how to write code are not much better, not for
> the work they have been entrusted with. One of them, actually said to
> me, "I don't really like all that data structures stuff, I just like to
> get things done."

If you think that engineering bozos are confined to the software
industry, you're badly mistaken. Just watch Modern Marvels' endless new
installments of "Engineering Disasters XXX".

Damien Kick

unread,
Dec 30, 2006, 11:31:15ā€ÆAM12/30/06
to
Carlos Moreno wrote:
> Andrei Alexandrescu (See Website For Email) wrote:
>> Carlos Moreno wrote:
>>
>>> Badly managed pointer arithmetic, memory overwrite, buffer overflows,
>>> double-deletion, dereferencing invalid/uninitialized/deleted/NULL
>>> pointers, etc. etc. etc. are the *real* problems regarding memory
>>> management. GC has absolutely nothing to do with any of those.
>>
>> I think this paragraph needs some major rethinking :o).
>
> I would ask you to elaborate on that, please?
>
> Ok, ok, I'm now noticing that double-delete would be addressed by
> GC, [...]

Double-delete would be addressed by GC because one would not explicitly
call delete. Dereferencing deleted memory, same.

> After rethinking a little bit, I'm still really puzzled by how some
> people --- putting aside whether it is fairly or unfairly --- talk
> about the big mess/hell that C++ applications are concerning memory
> management, as if the lack of GC was the obvious reason --- "with
> gabage-collected languages, none of these happen", I can hear them
> say! My point is, if with all instances of garbage-collected
> languages that exist none of these problems happen, then it is
> because of *other* features of those languages, and not because
> of GC.

Well, yes, you do have a point (half-pun half-intended). Raw pointers
will still be a huge source of problems even if one has GC.

T* p = new T;
*(++p) = T();

The above code will still be a problem even if we have a GC to notice
that nobody is currently pointing at the heap allocated T. But I don't
see how that fact that GC fails to solve all such problems is an
argument *against* GC. <gesture what="throwing the baby out with the
bath water"> Especially as having GC would allow for a coding style
which would allow for one to use raw pointers less.

T& p = *(new T);

GC can worry about cleaning up the memory for T so we don't need a
pointer with which to explicitly delete it. No raw pointer means no
chance to use pointer arithmetic to point to invalid memory.

Mirek Fidler

unread,
Dec 30, 2006, 11:31:37ā€ÆAM12/30/06
to

Le Chaud Lapin wrote:
> Andrei Alexandrescu (See Website For Email) wrote:
> > Carlos Moreno wrote:
> > > Badly managed pointer arithmetic, memory overwrite, buffer overflows,
> > > double-deletion, dereferencing invalid/uninitialized/deleted/NULL
> > > pointers, etc. etc. etc. are the *real* problems regarding memory
> > > management. GC has absolutely nothing to do with any of those.
> >
> > I think this paragraph needs some major rethinking :o).
> >
>
> What needs rethinking is the process by which the programmers get
> themselves this mess in the first place.

Well, while I can agree with your general GC view, I am not quite sure
that this time you are right, as you are unlikely to have

"double-deletion, dereferencing invalid/uninitialized/deleted/NULL
pointers"

in pure GC languages.

Mirek

Walter Bright

unread,
Dec 30, 2006, 11:36:04ā€ÆAM12/30/06
to
Carlos Moreno wrote:

> Walter Bright wrote:
>> It does far more than address memory leaks. It:
>>
>> 1) addresses dangling pointer bugs
>
> How?? The way I see it, it only changes the behaviour in the presence
> of accessing a dangling pointer --- worse: it is just hiding the
> symptom of the real problem (the eral problem being that there *is*
> a dangling pointer and someone is using it when they shouldn't).

You can't have a dangling pointer with GC. You'll never be accessing an
invalid object.

> IMHO, a better solution than GC is to make the behaviour of
> dereferencing invalid pointers perfectly defined --- it really is
> the infamous undefined behaviour the real cause of all the mess
> that is attributed to memory management in C++. If dereferencing
> an invalid pointer (*any form* of an invalid pointer --- deleted,
> uninitialized, NULL, etc.) threw an exception, things would be
> much, much better.

That's a nice idea, but it is unimplementable with current CPUs (if you
want any sort of efficiency).

> Again, we do not want to promote sloppiness from the prorgammers;
> hiding the symptoms of a problem and make it silently have no
> effect (or seem to have to effect) does not help; it promotes
> and fascilitates sloppiness.

I don't agree at all. Does automatic register allocation facilitate
sloppiness?


>> 2) removes the need to carefully keep track of who 'owns' a chunk of
> memory
> The compiler is very careful in keeping track of who owns what;
> and we already have the tools to leverage all this compiler power
> to automate memory management and relieve the programmer from the
> big nightmare.

Yes, such a tool is called GC <g>.

>> 3) (2) often results in a significant simplification of data structures
>> and algorithms
>
> I disagree. Well, or rather, I could claim that it is far more
> often that the "automatable" model of C++ memory management results
> in a simplification of data structures and algorithms.

You could so claim, but I have never seen a data structure that is
simpler for that reason. On the other hand, I can report that I can
dispense with reference counting members and functions, and often copy
constructors and destructors, and even assignment overloading, when I
switch to GC.

>> 4) (2) often results in higher speed and less bloat because there's no
>> longer a need to increment/decrement counts or deal with exception and
>> thread safety on those counts
>
> Higher speed and less bloat??? It depends on how you define higher
> speed and how you define bloat

higher speed - runs in less time
less bloat - smaller code and data size

> --- I could claim that GC is an
> unnecessary bloating of my apps; and as for speed; if I unpredictably
> have to wait who-knows-how-long because the garbage collector decided
> that it needed/wanted to act, I do not think that would qualify as
> "good speed" --- or, you could put it this way: you want speed? I
> need responsiveness.

There are many straightforward ways to deal with the pause issue with
GC, that problem was addressed at least 10 years ago.

> Speed, we have it almost for free nowadays
> with ever increasingly powerful hardware.

And we correspondingly demand ever more from them.

>> 5) surprisingly, GC can often lead to a much reduced need to allocate
>> memory, because much more sharing of data can happen
>
> Ok, good point. But again, in C++ you can already achieve the exact
> same level of data sharing, with pointers and without worrying about
> all the messy details of manual memory management (shared_ptr when
> you need it, custom data structures when you must)

shared_ptr<> is a messy detail itself <g>. As for the "exact same level
of data sharing", consider the following D programming language code:

char[] string = "hello world";
char[] foo = string[3..6];

foo now refers to "lo " in the string array (a copy is not created).
Supporting arbitrary interior references is pretty hard to do with
manual memory management, but it's almost a no-brainer with GC. If you
do manage it with C++, you certainly are going to be dealing with messy
details of manual memory management, as neither shared_ptr<> nor any of
the other standard library components can do it.

>> 6) makes it far easier to create reusable library code
>
> Maybe. Only, and with much stress, *maybe* ...

I think the evidence suggests it is with much less stress than with C++.

> I would really be willing to bet one month of my salary that none
> of any applications that any of my students (in that course) has
> ever created has any memory leaks, or any memory-management problem
> whatsoever; and we're talking about a lot of them (and as I said,
> most of them are far below "elitesque" level). Actually, wait,
> maybe some of them do have problems --- I'm now remembering that
> a few of those students had had prior experience programming in
> C; yep, I would bet another month of my salary that if there
> are any programs with memory management issues, is one created
> by some of those students with prior experience in C (well, or
> in C++, which they most likely had learned from the likes of
> Deitel & Deitel, which means that they had really learned C)

Student homework projects must be completable in a few hours, hence they
tend to be trivial. I don't think it's reasonable to assume the problems
they encounter are comparable to professional projects.

Walter Bright

unread,
Dec 30, 2006, 11:36:53ā€ÆAM12/30/06
to
Ion Gaztańaga wrote:
>> I've used leak detectors with C/C++ for 20+ years. The first generally
>> available (and still available) one is one I wrote and gave away 20
>> years ago: http://c.snippets.org/code/mem.txt They certainly help debug
>> memory allocation problems - but they don't make it any easier to
>> *design* robust memory management. They also don't guarantee correctness:
>>
>> 1) if you don't have a 100% comprehensive test suite
>> 2) for every path an exception might take through your code
>> 3) for threading issues
>> 4) for code you have to work with that cannot be instrumented
>> 5) for code you have to work with that uses different memory management
>> conventions
>
> 1) and 2) are not very convincing for me, because RAII its in our
> hands.

RAII is good for a certain class of simple problems, but is not a
general panacea for exception handling cleanup problems. For more
information, see http://www.digitalmars.com/d/exception-safe.html


> Of course, I can make mistakes, but if instead of using char[],
> I use std::string, I'm pretty sure that no memory will be leaked even
> every single statement of my function throws an exception. But I
> understand your points.

You've a potential resource leak every time you use operator new, and a
potential dangling pointer problem every time you use RAII. For example,
just store a reference to an RAII stack allocated std::string into a
global map.


> If you have memory that you don't know when it will be freed, it's
> clear that GC is a good option. C++ should definitely have it. But I do
> think that most memory allocations have an easy, single owner lifetime,
> and that can be easily managed using constructors and destructors (or
> even better, with a member auto_ptr/unique_ptr<>). The single ownership
> can be efficiently transferred through unique_ptr<>.
>
> For shared ownership, if we need to deterministically free resources
> (for example, when all the users of a net connection end their job we
> want to close the connection) shared_ptr<> is a good option, because
> the destructor will be called when the last reference dies.

And hopefully, you carefully did all the auto_ptr/unique_ptr/shared_ptr
decisions correctly, along with the transfers. Then when someone else
comes along and modifies your code, they don't botch that all up by
failing to understand all the subtle details of when to use which ptr type.


> For memory with uncertain or too complicated lifetime, GC is the right
> option. The problem is that, IMHO, making GC the default choice is not
> a good option. Although in theory GC *can* improve memory use, I think
> most of the problems with GC have relationship with a) finalization b)
> excessive memory use. And that's maybe because garbage collection is
> being used for tasks that are more efficiently (without any effort,
> like using unique_ptr/auto_ptr in single owner memory) handled with
> manual management.

GC isn't good for non-memory resource handling. I think a large part of
the problems people have with GC come from trying to bash it to handle
resources like file handles for which it is eminently unsuitable.
Essentially, if you need a destructor/finalizer, then you shouldn't be
using GC to manage it.

But the fortunate reality is that the vast majority of destructors are
needed to manage memory, and those can be dispensed with with GC.


> My experience is that both Java and Managed C++ desktop applications
> consume much more memory than their previous C++ incarnations. I'm not
> talking about old applications or environments and I'm not the only one
> with this feeling. But of course, this is only an impression and it's
> not a fact.

I don't know about Managed C++, but a big factor with Java memory
consumption is the lack of support Java has for POD and stack allocated
data. It forces too much onto the heap.


> My fear is not related with adding GC to C++ but with *how* it will be
> added. And which are the implications of "optional". For the moment, I
> can only see one proposal, and IMHO that proposal can silently break my
> old code, because my code was based in deterministic resource
> liberation and manual management. I would prefer a C++/CLI-like
> approach, because it's less intrusive and because creating a garbage
> collector that can eat pointer xor-ing, pointer operations like < or
> ==, and storing pointers inside any memory type, does not seem an easy
> task without paying some performance price (I'm not an expert, so don't
> take this statement too seriously).
>
> How I am supposed to write a generic code that can be used in
> environments both without GC (I must explicitly call delete[]) and with
> GC (no deterministic finalization, must call dispose manually) ? Should
> I write two control paths checking std::is_garbage_collected() at
> runtime?

I agree with your concerns there. I think it is too late for C++ to go GC.

> So, based on your experience, do you think that transparent garbage
> collection (N2128, new/delete garbage collected, scanning for pointers
> in integers if the class is not gc_strict, operator < and == with
> pointers, using pointers as hash keys...) can have performance issues
> or algorithm limitations comparing to a C++/CLI-like approach (a
> different pointer type, the compiler forbids castings on those
> pointers...)?
>
> There is no C++ finalization proposal yet AFAIK, and I think that
> having GC without solving finalization is not desirable. Which is, in
> your opinion, the best way to deal with finalization issues that have
> arisen in other languages (Java problems, for example, are mentioned
> N2128)?

The problems happen like when one decides that object-oriented
programming is the One True Path, and then tries to bash everything into
being an object. GC is not the One True Path. But it works well enough
for a large set of common problems. But when you need finalizers,
destructors, or to close file handles, GC is the wrong answer. The four
general forms of memory management are:

1) explicit
2) RAII
3) reference counting
4) GC

C++ supports 1,2,3, D supports 1,2,4. There's some ongoing investigation
between myself and colleagues on a way to support 3 in D, and then the
programmer will be able to select the right approach for the right problem.

Mirek Fidler

unread,
Dec 30, 2006, 11:30:53ā€ÆAM12/30/06
to
Nevin :-] Liber wrote:
> So you are basically arguing that we shouldn't be using a heap *at all*;
> no polymorphism, all lifetimes have to be LIFO, etc.

Well, I cannot speak for OP, but yes, actually, this is more or less
exactly what I am doing in my code. (Of course with the exception of
polymorphism, which has to be integrated with this paradigm, but there
are simple and elegant solutions to that problem). Heap is low-level
implementation issue - that is why I am always puzzled why so many
attention is given to this detail.

Such code is easy to write, easy to maintain and runs fast as hell.

But people would have to rethink and get rid off heapophilia first ;)

--
Mirek Fidler
U++ team leader. http://www.ultimatepp.org


--

Sergey P. Derevyago

unread,
Dec 30, 2006, 12:57:55ā€ÆPM12/30/06
to
Le Chaud Lapin wrote:
> I also think you should read the articles that are being written by
> Microsoft and ask yourself, honestly, what is the real difference
> between intellectual capacities to understand
> 1. C++ constructor(new)/destructor(delete)
> versus
> 2. C# special cases of finalize, dispose,
>
Current programmers are not supposed to understand. Current programmers are
supposed to pay _their_ money.

Look,
1. What we had in the past was: Some limited number of programmers that buy
professional tools to make some business.
2. What we have now is: A lot of "programmers" that buy nifty toy^Hols to get
some fun. Professional marketing experts invent cool bells and whistles for
them. Believe or not, it's a really big market of true amateurs.
--
With all respect, Sergey. http://ders.stml.net/
mailto : ders at skeptik.net

Lourens Veen

unread,
Dec 30, 2006, 12:57:32ā€ÆPM12/30/06
to
Nemanja Trifunovic wrote:
> I
> know very few C++ programmers interested in using GC with C++, so
> even if it is added odds are very few people will ever use it.

I was reading this thread and thinking about garbage collection and
whether I would want to have it. In the only multithreaded
shared-objects system I've ever built objects were created by one
thread, then passed on to another which put them in a queue, and when
removed from the queue they were "activated" and got their own
thread. They deleted themselves when they were finished. No GC
required. So I didn't see the need for GC.

Then I read the other thread about std::string, and started thinking
of how I would design a string library. If you have immutable
strings, then copies of strings or substrings don't have to actually
copy any data; they just refer to part of the original string's data.
So, now you have multiple string objects pointing to different bits
of heap-allocated memory. And that memory needs to be freed when
there are no more string objects pointing into them.

There are multiple well-know solutions to this problem. One of them is
reference counting, and the language offers support for that with
std::tr1::shared_ptr. But this means extra overhead for many
operations, and it may not be the most efficient way to do it.
Garbage collection may well be a better solution in this case.
Unfortunately, if I want to do that, the language offers no specific
support whatsoever. As someone else pointed out earlier in this
thread, I could implement it myself (especially in this case, where
all pointers are known and immutable and can register themselves upon
construction) but I would have to do so from scratch. It would be
nicer if the language offered support for this like it does for
reference counting.

Of course, as the OP fears, GC is a feature that is easily misused by
incompetent programmers. C++ has many such features, and as I
understand it, the spirit of the language is very much to have them,
and to count on the programmer to do the right thing. Trying to fix
the programmer by changing the language is futile.

Lourens

Joe Seigh

unread,
Dec 30, 2006, 12:59:39ā€ÆPM12/30/06
to
Mirek Fidler wrote:
>
> Well, I think that the real problem in fact is STL direction... It
> leads to complicated, over-engineered and hard to understand/maintain
> code. But the problem is that STL feels oh so cool idea. In fact, STL
> IS cool idea. But not every cool idea is suitable to do real job well.
>
> Related to this thread and STL, I think it was really bad idea to add
> container/algorithm library to object oriented language that is unable
> to work directly with objects. No wonder that there are so many
> requests for GC now...
>
I assume you're talking about the problem of returning a reference
to an object in an collection rather than returning a copy of the
object. There are a whole pile of issues there besides managing
object lifetime. GC can help solve the object lifetime issue but
that then makes it less obvious the programmer doesn't have a clue
what they're doing in the first place.


--
Joe Seigh

When you get lemons, you make lemonade.
When you get hardware, you make software.

Andreas Huber

unread,
Dec 30, 2006, 12:58:17ā€ÆPM12/30/06
to
Le Chaud Lapin wrote:
> Andreas Huber wrote:
>> Did they really claim "not difficult"? Where did you get that from?
>> I've only ever heard that things become easier.
>
> Microsoft Writes:
> "Last month, I described the motivation for garbage-collected
> environments: to simplify memory management for the developer."
> http://msdn.microsoft.com/msdnmag/issues/1200/GCI2

:-) Note the word "simplify", that's far away from "not difficult".

> '.NET 2.0 For Delphi Developers' writes:
> "At the same time, .NET offers garbage collection that frees us from
> memory management overhead."
> http://www.midnightbeach.com/.net/
>
> 'Sams Teach Yourself Visual C++. .NET in 24 Hours' writes:
> Using Managed Code for Easy Memory Management
> http://safari5.bvdep.com/0672323230/ch05lev1sec2"

Both references are not from Microsoft and therefore don't qualify to
justify your original claim:
<quote>
First, one of the
biggest selling points of managed applications was GC. The other
selling point, which was probably one of greatest marketing drugs in
the 20th Century was "managed", giving the idea that it is somehow
better than "unmanaged". So here we have that memory, managed, and
difficult, are all be used in the same sentence, being written by the
very organization that claimed to make these things not difficult.
</quote>

In this context it's pretty clear that with "organization" you could
only have meant Microsoft. I'm still waiting for Microsoft references
where they claim that memory management is "not difficult" with GC.
Don't bother though, if you try hard enough, I'm sure that you will
eventually come up with a reference from an MS employee who dared to say
that memory management with GC is easy or not difficult or whatever. My
point was that the majority of MS people usually don't say those things
because they know very well that it isn't true. You yourself delivered
evidence in that direction by quoting all those articles from Microsoft
that discuss problems with GC.

> While looking for references, I found this statement about Java. Why
> am I not suprised:
> "Although Garbage Collection (GC) in Java attempts to simplify memory
> management by relieving the developer from allocating, tracking and
> freeing memory, it still cannot totally eliminate memory leaks.
> Objects may be inadvertently kept beyond their useful lives, or may be
> referenced so that GC will not scoop them up. Detecting memory leaks,
> and finding and eliminating their root causes, are crucial steps in
> improving the performance of a Java application."
> http://websphere.sys-con.com/read/258406.htm

Yes, this is a well-known problem which often occurs when beginners with
no GC experience start to program in a GCed language. Such problems can
be solved easily with weak references (and better education).

>>> Any engineer who designs a program that contains these problems in
>>> such significant quantities as to warrant an article being written
>>> about it should be ashamed of him/herself.
>>
>> I fail to see how the above is relevant. A similar article could be
>> written about any language that offers manual dynamic memory
>> management (memory leaks, dangling pointers, etc.). As always, a
>> fool with a tool is still a fool. Ah, and don't get me started about
>> memory fragmentation problems in C++, but that's really beside the
>> point.
>
> But in this case the fools are trying to deposit their fools' gold in
> our bank because their bank went bankrupt.

Oh, did it?

> C++ is what it is. We stated that, if you are an engineer who knows
> how to build systems (in any engineering disciplines), and you are in
> tune with the mechanics of RAII constructor/destructor call sequence,
> then you should not have many problems with memory management. We did
> not claim more. We never said you could call new/delete willy-nilly
> and magic would happen. What you see is what you get.
>
> The GC people are saying that, if you use GC, it relieves you from
> having to think about memory management. This is a lie.

Without you giving more context, the above borders on being meaningless.
Who are the "GC people"? Microsoft, SUN, Hans Boehm and whoever else has
ever dared to propose GC as an alternative mode of memory management?
Even if you come up with a concise definition of "GC people", I doubt
you will ever be able to show that they really stated the above in
unison.

> That
> Microsoft is writing so many articles about how to "properly" do
> memory management under .NET is plain evidence of this fact.

And also plain evidence that Microsoft is aware that GC is no silver
bullet.

> The problem is that, though this lie is beginning to reveal itself in
> other languages, that doesn't seem to stop people from trying to
> reinvent it in the context of C++.

Do you really mean that people reinvent the lie in the context of C++?
If so, references please!

> The truth is that memory management is complex for any beginner. The
> only real hope for "proper" memory management is to engineer the
> system appropriately.

Right, that goes for both modes of memory management.

>> I clarify my original question: Let's say you have a software written
>> twice, once in C++ and once in a GCed language (C#, Java). One and
>> the same engineer writes both systems who is proficient in memory
>> management in C++ (RAII, smart pointers, etc) and GCed languages. I
>> believe the engineer will typically spend considerably less time
>> thinking about memory management when building the system in the
>> GCed language and that's all that counts in terms of usability.
>
> I disagree. I have no experience in C# and not much in Java, but I
> have used Lisp/Scheme much, and of course, C++. I don't think about
> memory management too much in C++, so C# would automatically lose. I
> spend most of my time thinking about
>
> 1. data structures and algorithms
> 2. clean interfaces so that users of my class will feel good when
> they use them
>
> Memory management is not on this list.

I would claim that you still do think about memory management but no
longer consciously because of years of experience. The same goes for a
programmer with years of experience in GCed languages. What counts here
is that beginners with no experience whatsoever are usually faster
writing usable code in GCed languages than they do in languages with
"manual" memory management.

> I have used the
> constructor/destructor model so many times, when I go to write
> Foo::~Foo(), I am almost disappointed, as there is not much to think
> about: get write of whatever memory was allocated in the constructor.
> As far as usability goes, as I stated earlier, I get more questions
> from programmers who switch to C#/.NET asking me to help them fix
> their memory management issues (over the Internet) than I ever got
> for C++.

What you observe is certainly a function of the fact that nowadays there
are many more (badly educated) newbies in GCed languages than there are
in C++.

> I also used to receive C++ questions also, but I can
> honestly say that the C# code is typically so sprawling and unwieldy
> that the best I can tell them is to get a box with more RAM.

I don't see how this is relevant.

> I also think you should read the articles that are being written by
> Microsoft and ask yourself, honestly, what is the real difference
> between intellectual capacities to understand

I have been giving courses on memory/resource management with
finalizers/Dispose for more than 4 years. I think that I have some
insight in the problems associated with GC.

> 1. C++ constructor(new)/destructor(delete)
>
> versus
>
> 2. C# special cases of finalize, dispose,

You seem to have overlooked the distinction I tried to make right at the
beginning. Finalize & Dispose are almost exclusively used in conjunction
with the management of non-memory resources (files, locks, whatever). I
acknowledged that GC does not relieve you from non-memory resource
management (in some GCed languages it is even harder than in C++ due to
the lack of scoping constructs for deterministic release).
Yes, there are uses of Finalize() for the management of memory, but
these are so seldom that it is safe to assume that your average
programmer will not have to implement any of those in years. Dispose()
is necessary more often, but still not as often as destructors in C++. I
therefore maintain my claim that *memory* management in GCed languages
is *typically* easier than it is in languages like C++.

--
Andreas Huber

When replying by private email, please remove the words spam and trap
from the address shown in the header.

Joe Seigh

unread,
Dec 30, 2006, 1:00:01ā€ÆPM12/30/06
to
Le Chaud Lapin wrote:
>
> While looking for references, I found this statement about Java. Why
> am I not suprised:
> "Although Garbage Collection (GC) in Java attempts to simplify memory
> management by relieving the developer from allocating, tracking and
> freeing memory, it still cannot totally eliminate memory leaks. Objects
> may be inadvertently kept beyond their useful lives, or may be
> referenced so that GC will not scoop them up. Detecting memory leaks,
> and finding and eliminating their root causes, are crucial steps in
> improving the performance of a Java application."
> http://websphere.sys-con.com/read/258406.htm
>

While not directly to the point but since you mentioned Java, most
(or some at least) of the Java garbage collectors exploit object
locality to reduce the number of objects that have to be GC'd. I.e.
objects are not allocated from GC'd memory unless they're referenced
outside of local scope. Local only objects are immediately dtor'd
as they leave scope.

This raises some interesting points. One is that pure GC is not as
efficient as some GC proponents would lead you to believe. The other
is that while you can use GC and get RAII like efficiency if the
GC implements it, you can't rely on it. So the ability to control
a major performance factor would be taken out of the hands of the
programmer.

And there are interesting situations like

for (;;) {
X x = new X();
...
}

A sufficiently smart compiler would recognise that the old
values of x can be collected right away. But do you want
programmers like that around? If they did that with something
with global scope, your application would spend most of it's
time in GC.

I suppose you could develop memory profiling tools that could
look for this kind of thing. There may be a trend here. We
develop smart tools so we can hire dumber programmers because
they're cheaper than good programmers.

--
Joe Seigh

When you get lemons, you make lemonade.
When you get hardware, you make software.

[ See http://www.gotw.ca/resources/clcm.htm for info about ]

Francis Glassborow

unread,
Dec 30, 2006, 1:05:20ā€ÆPM12/30/06
to
In article <cMilh.26224$e11.3...@weber.videotron.net>, Carlos Moreno
<moreno_at_mo...@mailinator.com> writes

>IMHO, a better solution than GC is to make the behaviour of
>dereferencing invalid pointers perfectly defined --- it really is
>the infamous undefined behaviour the real cause of all the mess
>that is attributed to memory management in C++. If dereferencing
>an invalid pointer (*any form* of an invalid pointer --- deleted,
>uninitialized, NULL, etc.) threw an exception, things would be
>much, much better.

Of course there is nothing to prevent an implementation from doing
exactly that :) However I suspect that it is much harder to do in
practice (somehow the program has to keep track of which pointers are
valid and which are not.

Consider:
void foo(mytype *);

int main() {
mytype * mt_ptr = new mytype;
foo(mt_ptr);
return 0;
}

Now is mt_ptr valid when foo returns? Yes of course it is in a well
designed program but that is not what we are talking about.


--
Francis Glassborow ACCU
Author of 'You Can Do It!' and "You Can Program in C++"
see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects

Bo Persson

unread,
Dec 30, 2006, 1:04:11ā€ÆPM12/30/06
to
Carlos Moreno wrote:
> Walter Bright wrote:
>
>>>> large part of program design time. These issues don't disappear
>>>> with GC, but they are 70-80% reduced with GC.
>>>
>>> I have to strongly disagree with these numbers; *memory
>>> management* problems tend to be nasty and hard-to-deal-with. But
>>> GC --- and correct me if I'm wrong --- only addresses memory
>>> leaks, which is by far, but really really really far, the least
>>> problematic of the categories of memory management issues.

>>
>> It does far more than address memory leaks. It:
>>
>> 1) addresses dangling pointer bugs
>
> How?? The way I see it, it only changes the behaviour in the
> presence of accessing a dangling pointer --- worse: it is just
> hiding the symptom of the real problem (the eral problem being that
> there *is* a dangling pointer and someone is using it when they
> shouldn't).
>

I you never delete anything, no pointer is ever dangling!

As long as you have a pointer, the object pointed to is still there, and
remains there. That way you don't have to define what happens to dangling
pointers!


Bo Persson

--

Ion GaztaƱaga

unread,
Dec 30, 2006, 1:02:21ā€ÆPM12/30/06
to
> Not quite, I am saying that efficient and safe multi-threaded
> programming will require exceptional skills in the future if it is done
> without GC. Manual memory management in a MT program either cripples
> modern hardware (by locking -- which is not cheap when that results in
> suspending 90% of your CPU power) or consumes an inordinate amount of
> highly skilled programmer time.

This is not very convincing. You suggest that you are passing pointers
to memory buffers between different threads like crazy? If the resource
is shared between threads you will need to synchronize access to that
memory, liberation is the less complex problem you have. Not to mention
that a C++ program does not spend all the time allocating heap memory,
because we have the stack (unlike other languages) and the stack is
thread-safe.

Apart from that, it seems that you compare an ultra-highly optimized GC
for multithreading with a poor allocator holding a giant lock and
traversing a sinly linked list of memory chunks yielding to linear
allocation time. The same techniques we apply to multhreaded collectors
can be applied to manual heaps (lock-free techniques). You should
compare apples and apples.

And even without lock-free techniques, there is solution for this:
per-thread heaps plus an application level heap. After all, we can't
continue using the same old heap if the underlying hardware has
radically changed.

When a thread requests memory, it takes it from its private heap
yielding to zero overhead (not even atomic primitives and
acquire/release). When it runs out of memory it takes memory from the
general pool. When the memory is freed and there is too much free
memory for a thread, transfers some of it to the general heap. You can
reduce your locking needs to a tiny fractionnot to mention that
debugging that allocator is far less complex than debugging a
lock-free, impressively complex garbage collector. I think Doug Lea has

If lock contention is the problem, there is already solution for this
using the same old good allocators. But I think that if all the threads
of your application are requesting continuosly memory to the heap all
the time, you have a design problem that should be better solved
changing your design.

Regards,

Ion

Roland Pibinger

unread,
Dec 30, 2006, 1:04:34ā€ÆPM12/30/06
to
On 29 Dec 2006 19:31:31 -0500, "Mirek Fidler" wrote:
>Well, I think that the real problem in fact is STL direction... It
>leads to complicated, over-engineered and hard to understand/maintain
>code. But the problem is that STL feels oh so cool idea. In fact, STL
>IS cool idea. But not every cool idea is suitable to do real job well.
>
>Related to this thread and STL, I think it was really bad idea to add
>container/algorithm library to object oriented language that is unable
>to work directly with objects. No wonder that there are so many
>requests for GC now...

That's certainly the real problem. There is a clash of 'paradigms' in
the 'multi-paradigm' language C++. If C++ had containers for objects
the everyday usage of the language would be substantially improved.

Best regards,
Roland Pibinger

Dave Harris

unread,
Dec 30, 2006, 1:03:23ā€ÆPM12/30/06
to
c...@ntllib.org (Mirek Fidler) wrote (abridged):
> The real questionis: Should GC call destructors when sweeping objects?

No, it should not.

-- Dave Harris, Nottingham, UK.

It is loading more messages.
0 new messages