When to use a garbage collector?

[Jerry Coffin]

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.

 

[Stefan Ram]

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?

 

[Kai-Uwe Bux]

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

 

[Jerry Coffin]

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?

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. A decision that there's no alternative but to print an error
message and die is obviously the kind that's delayed the longest -- i.e.
you either handle an exception constructively or you allow it to
percolate up the stack (or maybe both).

At some point up the stack you reach a point at which the code knows the
environment in which it is executing, and therefore knows how to print
out an error message -- it might be a message window, or written to the
standard error stream, or written to a log file. In an embedded system,
it might just light up an LED or something on that order.

Asking me to predict the precise fashion of communication with the user
"in the general case" sounds a bit ridiculous, at least to me. As I said
previously, one of the strengths of exception handling is specifically
to allow such a decision to be delayed to the point that enough is known
about the specific environment to make such a decision. Asking me to
make such a decision ahead of time for every possible situation
obviously runs directly contrary to that.

 

[Jerry Coffin]

[ ... ]

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...

 

[Krice]

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."

 

[Bo Persson]

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.

"Error: object can't be constructed."

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


Bo Persson

 

[Stefan Ram]

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

»The central point in the exception handling design was
the management of resources.

In particular, if a function grabs a resource how can the
language help the user to ensure that the resource is
correctly released upon exit even if an exception occurs?«

from »6.4 Exception Handling« in »A History of C++: 1979 - 1991«
by Bjarne Stroustrup

This might be related to the problem that a constructor can
not return a status code to indicate success or failure of the
construction as it is expected to return an object. Also, some
other functions that should return a value (like »log«) can
not return a status code. So some other means to convey the
status were required.

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.

 

[Maik Beckmann]

[ ... ]

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


-- Maik

 

[coal]

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]

[ ... ]

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.

 

[Jerry Coffin]

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.

"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.

 

[James Kanze]

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.

"Error: object can't be constructed."

Respond to the request with an "insufficient 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
"insufficient 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]

[ ... ]

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.

That was probably true at the beginning, but now adays, just
about everybody thinks they have to write about C++, and most of
what I see is junk. (Joel Spolsky is probably better than
average, in fact, although I wouldn't consider him an authority
in any of the fields he writes about.)

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.

Scott is actually one of the few who really knows what he is
talking about. Go down to your local bookstore, randomly pick
up any number of books about C++, and see how many are written
by someone who has any idea what they are really talking about.

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...)

There are certainly some exceptions, and we (you and I) know
them. On the other hand, they are how many, compared to all of
the authors of "C++ for NULL's", "C++ in 7 Days", or whatever.
Take a look at the various web sites proposing C++ information:
how many of them are useful, or even correct? For every Sutter,
it seems like there are dozens of Schildts.

[ ... ]

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...

I was about to say... The reason why it needs to be standard is
because it's not just a library issue.

 

[James Kanze]

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?

Hmmm. I don't think I've ever had an application where there
were no cycles. Cycles are everywhere, starting with double
linked lists. Navigation between objects is rarely
unidirectional.

Whether this is relevant to the argument at hand is a different
question. Nobody but a fool would recommend just replacing all
raw pointers with boost::shared_ptr. On the other hand, there
are small subsets of the overall problem where it is the
appropriate solution---sometimes even when you're using garbage
collection for the general case.

The power of C++ is that it offers such alternatives.

gc's are no silver bullet. They may be good in some scenarios
but I don't think they are good in any situation.

(I suspect that you meant every, not any.)

Plus memory management is just a small part of resource
management in a C++ program (at least in my programs).

Memory tends to be somewhat different from other resources
because its use is so ubiquious, and also because there's so
much of it, and release doesn't normally have any other side
effects. Also, memory is where "objects" reside, and as such,
is involved in issues such as type safety.

 

[James Kanze]

Carlo Milanesi wrote:

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

That's one of the best summaries I've heard. I would add two
things, however:

-- For objects with value semantics, don't use dynamic
allocation at all. (I know you're aware of the tradeoffs,
but lately, we've seen a lot of people coming from Java who
allocate everything dynamically---even things like Complex.)

-- Neither garbage collection nor (usually) reference counting
deterministically define object lifetime. Objects whose end
of lifetime must have visible side effects (and that's most
of the dynamically allocated objects in some types of
application) still need code to manage this.

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

Yes and no. Simply replacing the global operator new and
operator delete to use garbage collection will result in more
reliable code, even if the application was originally written
without garbage collection in mind.

 

[Jerry Coffin]

(e-mail address removed)>, (e-mail address removed)
says...

[ ... ]

That was probably true at the beginning, but now adays, just
about everybody thinks they have to write about C++, and most of
what I see is junk. (Joel Spolsky is probably better than
average, in fact, although I wouldn't consider him an authority
in any of the fields he writes about.)

Quite true -- there are definitely worse around the Spolsky.

[ ... ]

There are certainly some exceptions, and we (you and I) know
them. On the other hand, they are how many, compared to all of
the authors of "C++ for NULL's", "C++ in 7 Days", or whatever.
Take a look at the various web sites proposing C++ information:
how many of them are useful, or even correct? For every Sutter,
it seems like there are dozens of Schildts.

Unfortunately, all too true. The one good point is that since C++ has
"gone out of fashion", many (perhaps most) of the worst have moved on
and are turning out dreck about Ruby on Rails, or whatever this week's
fad happens to be...

[ ... ]

I was about to say... The reason why it needs to be standard is
because it's not just a library issue.

I still think the standard should be written to _allow_ almost any sort
of GC (including copying collectors) but not to require any sort.

 

[Maik Beckmann]

[ ... ]

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

Found this
http://www.ddj.com/cpp/184401632

If you know more links please post them.

 

[James Kanze]

(e-mail address removed)>, (e-mail address removed)
says...
[ ... ]

That was probably true at the beginning, but now adays, just
about everybody thinks they have to write about C++, and most of
what I see is junk. (Joel Spolsky is probably better than
average, in fact, although I wouldn't consider him an authority
in any of the fields he writes about.)

Quite true -- there are definitely worse around the Spolsky.

I think an important distinction is that Spolsky never claimed to
write about C++. He writes about software development from a CTO /
CEO / Development manager perspective and touch a lot of subject.
However, he generalises and doesn't really go into the low level
details. That's fine for what he writes about. A CTO shouldn't
micro-manage and must generalise even if generalisation are sometimes
wrong. It's the job of the technical specialist to correct the CTO
when details are wrong

Certainly. He writes about software engineering. But even
there, I wouldn't consider him a reference. He's obviously more
competent than most, but his presentations are more annecdotal
than anything else.

OTOH Meyer / Alexandrescu / Sutter write specifically about C++ and go
into details and must get the details right. As long as one doesn't
try to define good class design from Spolsky's writings or use "Modern
C++ Design" for fresh graduate interview questions, there shouldn't be
too much problems.

IMO, what causes more damage are the "Learn C++ in 24 hours for null
dummmies" type of books or even worse, ex-C programmers that have been
promoted to management, have never bothered updating their skill sets
and are now promoting / recommending / imposing 20 years out of date
techniques from a totally different language to junior programmers.

That's sometimes a problem: a lot of university courses here got
upgraded from C to C++ without the prof bothering to learn the
new language, at least not any more than using new/delete
instead of malloc/free. The result is a large number of
beginners who really don't know C++, even though they've learned
it at school. In practice, however, I don't find that too great
a problem: there are so many things you don't learn in school,
and if the person is in any way competent, with a good mentor,
he'll catch on quickly. If I look at the experienced C++
programmer (the ones who will serve as mentors), I see a lot of
extremes---either C++ as they learned it, twenty years ago, or
the most complicated TMP from Alexandrescu's book to solve the
simplest, one of problem. (In my experience, the latter seem to
outnumber the former by better than two to one.)

 

[Krice]

Yannick Tremblay kirjoitti:

message: "Memory full, please close some other applications". Do you
think this is a bad idea and that it would be better for the mobile to
shutdown and turn itself off?

All these examples where memory recovery is needed seem to be
anything else than normal application running in PC, so I guess
it's good to have exceptions when they have some kind of real
function, but I think it's a waste of time to write such code in
PC application, because the construction never(?) fails, unless
you run out of memory.