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

[Jerry Coffin]

In article <MP************ ************@ne ws.sunsite.dk>,
jc*****@taeus.c om says...

[ ... ]

That's the whole point of using an exception: delaying handling of the
error until you reach a point at which it's apparent how it should be
handled.

Pardon me -- it's not really the _whole_ point, but merely part of the
point. Nonetheless, it's an important part of the point...

--
Later,
Jerry.

The universe is a figment of its own imagination.

[Krice]

On 11 kesä, 20:33, Jerry Coffin <jcof...@taeus. comwrote:

Oh my. In most cases you can do something reasonably productive when an
exception gets thrown.

Like what? If the object can't be constructed then there is
something seriously wrong and the program can't obviously
recover from that.

Even in the worst case, you probably want to
catch it and print out the most meaningful error message you can

"Error: object can't be constructed."

[Walter Bright]

Carlo Milanesi wrote:

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?

For scarce resources, like resource handles and large memory blocks, use
reference counting. For routine memory allocations, use gc.

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?

Using gc effectively entails using different coding/design techniques,
so it is not practical to try to shift the design after the fact.

-------------
Walter Bright
Digital Mars
http://www.digitalmars.com
C, C++, D programming language compilers

[Bo Persson]

Krice wrote:

On 11 kesä, 20:33, Jerry Coffin <jcof...@taeus. comwrote:

>Oh my. In most cases you can do something reasonably productive
when an exception gets thrown.

Like what? If the object can't be constructed then there is
something seriously wrong and the program can't obviously
recover from that.

The task being performed might fail, but not the whole server.

>

>Even in the worst case, you probably want to
catch it and print out the most meaningful error message you can

"Error: object can't be constructed."

"Query result too large - please use a more specific selection"
Bo Persson

[Maik Beckmann]

Jerry Coffin wrote:

[ ... ]

Very interesting. Are there nice readings in the inet about this topic,
which include some C++ snippets for everday usage?
-- Maik

[Chris Thomasson]

"Krice" <pa****@mbnet.f iwrote in message
news:4f******** *************** ***********@z72 g2000hsb.google groups.com...
On 11 kesä, 20:33, Jerry Coffin <jcof...@taeus. comwrote:

Oh my. In most cases you can do something reasonably productive when an
exception gets thrown.

Like what? If the object can't be constructed then there is
something seriously wrong and the program can't obviously
recover from that.

Not always true. Lets say that the object requested a synchronization
resource from the OS, but failed because too many of them were in use my the
program. Well, the exception handler could run some "purge" procedures to
try an rid itself of cached unnecessary state, ect... and defer trying again
to a later time. On a server, if an object fails construction during the
initialization process of a new connection, the exception handler could send
a message to the client application saying something like "Server overload;
try again later.". I could go on and on. The main point is that an
application can attempt to mutate the conditions which caused the exception
and defer trying again until things settle down. Sometimes, you can recover
from exceptions quite nicely.

One example in C... If malloc returns NULL, what do you do? Well, you could
try something like:

http://groups.google.com/group/comp....7956d31e6ca5cc

;^)

[coal]

On Jun 11, 1:50*pm, "Bo Persson" <[e-mail] te:

Krice wrote:

On 11 kesä, 20:33, Jerry Coffin <jcof...@taeus. comwrote:

Oh my. In most cases you can do something reasonably productive
when an exception gets thrown.

Like what? If the object can't be constructed then there is
something seriously wrong and the program can't obviously
recover from that.

The task being performed might fail, but not the whole server.

Yes, I think this sort of situation should be considered:

AccountBase
|
Account1_1
|
Account1_2

If the program is expecting to receive an Account1_2 object
over a network and a read fails/times out, I want to have the
object preserved as an Account1_1 if that much of the object
was successfully received. In baseball sometimes a hit is more
than a single, but not a double. If a runner tries to turn it
into a double he's thrown out. A double is better than a
single, but a single is much better than an out.

Brian Wood
Ebenezer Enterprises
www.webEbenezer.net

[Jerry Coffin]

In article <ex************ *************** ****@ram.dialup .fu-berlin.de>,
ra*@zedat.fu-berlin.de says...

[ ... ]

Ada83, and possibly already Algol68 and Clu had exceptions,
but I do not know who first came up with this concept.
Maybe it is inspired from processors, which might raise
interrupts, error signals or traps to invoke handlers.

PL/I had them in 1964. BASIC has had some exception handling-like stuff
(e.g. on error goto) for quite a while as well, though I'm not sure
whether it was in the original 1964 version or not.

--
Later,
Jerry.

The universe is a figment of its own imagination.

[Jerry Coffin]

In article <4f6f494b-3511-4d36-89ac-2f0d32f49877
@z72g2000hsb.go oglegroups.com> , pa****@mbnet.fi says...

On 11 kesä, 20:33, Jerry Coffin <jcof...@taeus. comwrote:

Oh my. In most cases you can do something reasonably productive when an
exception gets thrown.

Like what? If the object can't be constructed then there is
something seriously wrong and the program can't obviously
recover from that.

Maybe it can and maybe it can't. It depends entirely on what kind of
object you're trying to create and how important it is to the program.
In some cases it truly is crucial to the program, and all you can do is
print out the error message and quit. In other cases, it may be purely
cosmetic, and the program can do its real work without it. In still
other cases, there may be _other_ things that are more or less cosmetic
that can be discarded when/if necessary to allow the real work to
finish.

Just for example, I've written quite a few programs that have some sort
of windowed interface. Many of them display some sort of bitmap in the
background -- but if the system runs low of memory, they can discard the
bitmap, and get along with a plain grey background for a while.

Even in the worst case, you probably want to
catch it and print out the most meaningful error message you can

"Error: object can't be constructed."

Usually you can come up with something more meaningful than that -- at
the very least, something about the type of object whose construction
failed, and the operation(s) being attempted when the failure happened.

--
Later,
Jerry.

The universe is a figment of its own imagination.

[James Kanze]

On Jun 11, 9:37 pm, Krice <pau...@mbnet.f iwrote:

On 11 kesä, 20:33, Jerry Coffin <jcof...@taeus. comwrote:

Oh my. In most cases you can do something reasonably
productive when an exception gets thrown.

Like what? If the object can't be constructed then there is
something seriously wrong and the program can't obviously
recover from that.

It depends why the object can't be constructed. There are a lot
of things one can recover from.

Even in the worst case, you probably want to catch it and
print out the most meaningful error message you can

"Error: object can't be constructed."

Respond to the request with an "insufficie nt resources" error
(in case of bad_alloc, for example)?

Like most things, exceptions have a cost---in particular, they
do disrupt program logic. There are some specific cases,
however (not many, really, but although few, they occur fairly
frequently) in which the cost of the alternatives is higher. If
you run out of memory processing a request in a server, you
can't just bring the server down; you have to respond with an
"insufficie nt resources" error (and continue to accept simpler
requests). And there's no way to check before constructing an
object that it will have sufficient memory, so you have no
choice but to detect the error in the constructor.

--
James Kanze (GABI Software) email:ja******* **@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]