[bt-devel] Programming Techniques

[David White]

On Sat, 2002-03-16 at 00:54, Tim Brodie wrote:
> David White wrote:
> > 
> > QT may not use exceptions, but that is a completely different thing to
> > new not throwing an exception. QT could possibly force new to not throw
> > bad_alloc, by changing its definition; however I would suggest that
> > enforcing such non-standard behaviour upon users would be A Bad Thing.
> 
> There was a long and detailed conversation on the KDE-Devel list a month
> or two ago regarding out-of-memory handling within KDE (which is based
> on the Qt libraries).  IIRC, the recommendation was not to worry about
> it, since:
> a) heap exhaustion can be driven by a number of things, including user quota,

yes; that's right.

> b) there was no strategy uncovered within the KDE world to successfully 
> 	recover from heap exhaustion... once it happens you're effective
> 	dead in the water.  You can't even present a dialog even if it
> 	already exists because of transient memory requirements during the
> 	presentation of the dialog.

well, firstly, there should be a non-allocating way to display an error
message. If necessary, just use std::cout to write a message to the
console, but preferably display a dialog. Also, if one uses the RAII
technique I presented consistently, and one is using a
Standard-conforming implementation of new, new will throw bad_alloc;
this will mean that the stack will be unwound, and allocated memory
freed up. After it has unwound far enough (perhaps back to main),
sufficient memory may have been freed up to display a heap-allocating
dialog box before exiting. This is *alot* more elegant than crashing,
and not terribly difficult to implement so long as one has a
Standards-conforming new implementation.

There is a discussion going on at the moment on comp.lang.c++.moderated,
with David Abrahams, and others arguing that it *is* possible to recover
from heap exhaustion, and continue execution elegantly. While this may
take a substantial amount of effort, I think it's A Good Thing to use a
structure which would at least support this.

> c) checking for NULL from new was redundant, as the whole app will 
> 	terminate on this condition before ever returning to your app.

What is it that sets new to exhibit this non-conforming behaviour? I
would like to investigate overriding this to exhibit conforming
behaviour, so that BibleTime can behave sensibly upon heap exhaustion. I
see no good reason why a library developer would see fit to override a
language's default and very well-thought out behaviour for certain
critical events when a very well-defined and elegant way of solving the
problem at hand already exists.

> 
> I could have a faulty memory, so best to check the list archives over
> the last couple of months.  It turned out to be a rather vocal 
> argument that the moderator killed after a while.  Apparently, memory
> management can be a rather religious issue.

Well, it'd be nice to look it up...

God Bless,

David.

> 
> --
> We do not see things as they are; we see things as we are.
> 
> Tim Brodie, IT Manager, Display Works Inc.
> 90 Milvan Drive, Toronto, Ontario CANADA M9L 1Z6
> Phone: 416-740-9677x29 Fax: 416-740-9971 http://www.displayworksinc.com