Jim Helman (jimh++at++surreal)
Wed, 13 Sep 95 21:20:36 -0700
In general global new and delete operators are bad. They are
not very extensible since there is only ONE global delete
operator, and it must know how to delete anything created by
any global new operator. Performer 1.2 creates an overloaded
new operator with an extra argument and also overrides THE
global delete operator. So if you define an additional
global new operator that returns pfMalloc(size_t), DON'T
overload the global delete operator, we have special magic in
ours.
Lionel's suggestion is better because it creates new and
delete operators scoped to a class. This is what Performer
2.0 does internally (we no longer muck with global new and
delete). But this doesn't help for newing atomic types like
float, int, etc.
Also, note that if you do overload a new operator whether
globally or locally in a class, DO NOT "new" arrays. The
following sequence with a user-defined new operator:
foos = new((arena *)NULL) foo[n];
delete[] foos;
is a really bad idea. The "new" works fine, but the "delete"
could end up invoking foo's destructor on the wrong pointers
some number of times (n: 0 <= n < 2<<31) and will then
attempt to free a bogus address.
Surprise. Surprise. Surprise.
The compiler guys tell me this is not a bug in SGI's C++
compiler, but a "feature" of the language. When the C++
language was changed so that 'delete [n] foos;' became
'delete [] foos;', inside C++ arrays now needed to cache
their lengths. Unfortunately, C++ semantics do not allow
this to be not supported for an overloaded new operator.
rgds,
-jim helman
jimh++at++surreal.asd.sgi.com
415/390-1151
This archive was generated by hypermail 2.0b2 on Mon Aug 10 1998 - 17:51:53 PDT