When to use a garbage collector?

[Carlo Milanesi]

Hello,
traditionally, in C++, dynamically allocated memory has been
managed explicitly by calling "delete" in the application code.

Now, in addition to the standard library strings, containers, and
auto_ptrs, gurus suggest that may be better to use a reference-counted
smart pointer, or a garbage-collector.

But in which cases it is better to use one technique and in which cases
another? IOW, which is the design criterion?

And if, after having completed a working system, a technique would
result more performing than another, or better for other reasons, is it
advisable to change the memory management strategy of that working system?

--
Carlo Milanesi
http://digilander.libero.it/carlmila

[dizzy]

Pascal J. Bourguignon wrote:

Carlo Milanesi <ca************ ********@libero .itwrites:

>Hello,
traditionally, in C++, dynamically allocated memory has been
managed explicitly by calling "delete" in the application code.

Now, in addition to the standard library strings, containers, and
auto_ptrs, gurus suggest that may be better to use a reference-counted
smart pointer, or a garbage-collector.

But in which cases it is better to use one technique and in which
cases another? IOW, which is the design criterion?

Reference counted smart pointers: never. They leak memory as soon as
you have bidirectionnal associations or cycles in your data
structures.

By that logic you mean he will always have bidirectional associations or
cycles in his data structures (thus NEVER use shared_ptr). In my years of
C++ I've had that very rare and when I did, I used weak_ptr to break the
cycle. How often do you have bidirectional associations in your data
structures? In thos projects that you have, which percent of the data
structures from the project has cycles?

Garbage collectors: always. There are even real-time garbage
collectors, if you have real-time constraints.

gc's are no silver bullet. They may be good in some scenarios but I don't
think they are good in any situation. Plus memory management is just a
small part of resource management in a C++ program (at least in my
programs).

Well, usually garbage collectors give better performance.
http://www.jwz.org/doc/gc.html
But of course it depends on the application and datasets.

Ah so then you contradict your previous "Garbage collectors: always".

--
Dizzy

[Pascal J. Bourguignon]

dizzy <di***@roedu.ne twrites:

Pascal J. Bourguignon wrote:

>Carlo Milanesi <ca************ ********@libero .itwrites:

>>But in which cases it is better to use one technique and in which
cases another? IOW, which is the design criterion?

Reference counted smart pointers: never. They leak memory as soon as
you have bidirectionnal associations or cycles in your data
structures.

By that logic you mean he will always have bidirectional associations or
cycles in his data structures (thus NEVER use shared_ptr). In my years of
C++ I've had that very rare and when I did, I used weak_ptr to break the
cycle. How often do you have bidirectional associations in your data
structures? In thos projects that you have, which percent of the data
structures from the project has cycles?

Often enough. But the main point is of course, if your language
doesn't allow you to express some ideas easily, then you won't try to
express those ideas. If having circular references in C++ is a PITA,
then we will try very hard to avoid them. (And thus, burning a lot of
wetware cycles that would be better allocated to resolving the true
problems, instead of these technicalities) .

>Well, usually garbage collectors give better performance.
http://www.jwz.org/doc/gc.html
But of course it depends on the application and datasets.

Ah so then you contradict your previous "Garbage collectors: always".

Not really, in the following sentence you cut out, I explained that if
the currrent garbage collection algorithm wasn't good enough for your
application, it would be better to change this garbage collection
algorithm for another one more adapted to your particular
circumstances, rather than going back to manage memory manually.

--
__Pascal Bourguignon__

[dizzy]

Fran wrote:

On Jun 10, 5:37 pm, acehr...@gmail. com wrote:

>The problem is, that complex code hoping to figure out when to
'delete' an object may never be executed. The non-throwing lines of
code of today can suddenly start possibly throwing in the future by
code changes, and the explicit delete statement may never be executed.

Is there any chance that C++0x will give us mandatory checking of
throw() clauses in function definitions? That would enable the
compiler to warn about leaks when exceptions might happen between
calls to new and delete.

Why is there such a need? Always assume anything may throw and code
accordingly. In the exceptional cases where writing exception safe code is
not possible (making the code expensive or error prone) I'm sure you can
find a solution (like std::stack has for top()/pop()).

--
Dizzy

[Krice]

On 11 kesä, 00:25, acehr...@gmail. com wrote:

void foo()
{
A * a = new A(/* ... */);
/* code that may throw today or some time in the future possibly
after some code change */
delete a;

}

Throw what? A ball?

[Jerry Coffin]

In article <bcb28001-8bed-4732-8191-b97f61e511b3
@k13g2000hse.go oglegroups.com> , ja*********@gma il.com says...

[ ... ]

The first quote appears to be purely apocryphal -- an
unsupported statement from somebody posting under a pseudonym,
about software of unknown origin written by people of unknown
skills.

The first quote is probably the one which does correspond most
to practical reality; I seem to recall a similar statement being
made by Walter Bright (who certainly does qualify as a C++
guru). But of course, it doesn't have to be that way.

Right -- my point wasn't that the quote was wrong, only that it didn't
really add much. If somebody disagreed with (essentially) the same point
when I said it probably wouldn't find much in this to convince them (of
anything).

Joel Spolsky spends a lot of time writing about software, but
his credentials seem questionable at best. In particular, I've
seen nothing to give a really strong indication that he's much
of a programmer (himself) at all.

Another case of "those who can, do; those who can't teach (or
write articles)".

....except that most of the people I can think of who write specifically
about C++ really _can_ write code, and most of them clearly _do_, and as
a rule do it quite well at that. The only prominent exception would be
Scott Meyers, who's pretty open about the fact that he consults about
C++, teaches C++, but does NOT really write much C++ at all. OTOH, I'm
pretty sure that if he really needed (or wanted to) he could write code
quite nicely as well -- though given his talents as a teacher, I think
it would be rather a waste if he spent his time that way.

Others, however (e.g. David Abrahams, Andrei Alexandrescu, Andrew
Koenig, Herb Sutter) who write about C++, also appear to write a fair
amount of code, and mostly do it quite well at that (and no, I'm not
claiming to be such a guru that I'm in a position to rate the experts,
or anything like that...)

[ ... ]

When you get down to it, despite being umpteen pages long, the
criticisms in this paper that have at least some degree of
validity with respect to current C++ can be summarized as:

1) member functions should be virtual by default.

Which is just wrong, at least from a software engineering point
of view.

Right -- I don't mean to imply that all these are correct, or anything
like that -- I just mean that:

1) they're clearly enough defined to be fairly sure what he's saying.
2) they aren't obviously obsolete.
3) They aren't simply of the form: "Eiffel does it differently."

They're points that can be discussed intelligently, their strengths and
weaknesses can be examined, etc. They're not necessarily right, but at
least you can define (to at least some degree) what it means for them to
be right or wrong.

[ ... ]

I don't think that there is complete consensus among the gurus
as to when garbage collection would be appropriate. I would be
very suspicious, however, of anyone who claimed that it is
always appropriate, or never appropriate. That it's not
available in the standard toolkit is a definite flaw in the
language, but requiring it to be used in every case would
probably be even worse (but I don't think anyone has ever
proposted that).

I'm not sure it really needs to be part of the standard library, but I
do think it would be a good thing to tighten up the language
specification to the point that almost any known type of GC could be
included without leading to undefined behavior -- but we've been over
that before...

--
Later,
Jerry.

The universe is a figment of its own imagination.

[Pascal J. Bourguignon]

Jerry Coffin <jc*****@taeus. comwrites:

I'm not sure it really needs to be part of the standard library, but I
do think it would be a good thing to tighten up the language
specification to the point that almost any known type of GC could be
included without leading to undefined behavior

Well said!

-- but we've been over
that before...

Ok.

--
__Pascal Bourguignon__

[acehreli]

On Jun 11, 6:56 am, Krice <pau...@mbnet.f iwrote:

On 11 kesä, 00:25, acehr...@gmail. com wrote:

void foo()
{
A * a = new A(/* ... */);
/* code that may throw today or some time in the future possibly
after some code change */
delete a;

}

Throw what? A ball?

No, an exception; unless you are imagining a type named "ball" of
course. :p

I can't believe you are serious; you must have forgotten the smiley...
Seriously though, if you really didn't know what I meant with "throw,"
you should learn about exceptions.

Ali

[Krice]

On 11 kesä, 19:43, acehr...@gmail. com wrote:

Seriously though, if you really didn't know what I meant with "throw,"
you should learn about exceptions.

Exceptions are not logical. If construction of the object
fails then what? The program fails also, usually. I never
check anything, not since they invented exceptions, so
I'm assuming that there are no exceptions:)

[Jerry Coffin]

In article <d9177235-e278-46e6-a709-cdac9bb80a53
@b1g2000hsg.goo glegroups.com>, pa****@mbnet.fi says...

On 11 kesä, 19:43, acehr...@gmail. com wrote:

Seriously though, if you really didn't know what I meant with "throw,"
you should learn about exceptions.

Exceptions are not logical. If construction of the object
fails then what? The program fails also, usually. I never
check anything, not since they invented exceptions, so
I'm assuming that there are no exceptions:)

Oh my. In most cases you can do something reasonably productive when an
exception gets thrown. Even in the worst case, you probably want to
catch it and print out the most meaningful error message you can, which
is typically quite a bit more than the runtime library is likely to do
on its own.

--
Later,
Jerry.

The universe is a figment of its own imagination.

[Kai-Uwe Bux]

Stefan Ram wrote:

Jerry Coffin <jc*****@taeus. comwrites:

>>Oh my. In most cases you can do something reasonably productive when an
exception gets thrown. Even in the worst case, you probably want to
catch it and print out the most meaningful error message you can

A function should not be coupled to an application more than
necessary, so that the function might be used in a library as well
(or one might even write functions for use in a library).

Usually, a function does not know which user interface the
program calling it employs. »::std::cout« might be associated
with a console, or it might not be, when the application is GUI
based, web based or a driver or a service without a user interface.

So what should »print out« mean in the general case?
Should the function use »::std::cout << ...« or what else to
»print out« the most meaningful error message it can?

Of course, printing a message for the user is the last resort. We must
assume that all better ways of responding in a more specific way are
blocked (for whatever reason). In that case, at a point where you cannot
determine what "print out" means, you still have the option of letting the
exception propagate higher in the call stack. At some point, it has to be
known what "print out" means.
Best

Kai-Uwe Bux