1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
|
The bf(C++) run-time system ensures that when memory allocation fails an
error function is activated. By default this function throws a
hi(bad_alloc)hi(exception: bad_alloc)em(bad_alloc) exception (see section
ref(STDEXC)), terminating the program. Therefore it is not necessary to check
the return value of operator tt(new). Operator tt(new)'s default behavior may
be modified in various ways. One way to modify its behavior is to redefine the
function that's called when memory allocation fails. Such a function
must comply with the following requirements:
itemization(
it() it has no parameters;
it() its return type is tt(void).
)
A redefined error function might, e.g., print a message and terminate
the program. The user-written error function becomes part of the allocation
system through the function ti(set_new_handler).
Such an error function is illustrated below+footnote( This implementation
applies to the i(GNU) bf(C/C++) requirements. Actually using the program given
in the next example is not advised, as it probably enormously slows down your
computer due to the resulting use of the operating system's emi(swap area).):
verbinclude(-a examples/newhandler.cc)
Once the new error function has been installed it is automatically invoked
when memory allocation fails, and the program is terminated. Memory
allocation may fail in indirectly called code as well, e.g., when constructing
or using streams or when strings are duplicated by low-level functions.
So far for the theory. On some systems the `i(out of memory)' condition
may actually never be reached, as the operating system may interfere before
the i(run-time support system) gets a chance to stop the program.
The traditional memory allocation functions (like ti(strdup), ti(malloc),
ti(realloc) etc.) do not trigger the tt(new) handler when memory allocation
fails and should be avoided in bf(C++) programs.
|
