C++ new/delete operator with shared arena in 2.0

New Message Reply Date view Thread view Subject view Author view

Nicolas Gauvin (nicolas++at++cae.ca)
Fri, 15 Dec 1995 21:31:05 -0500


In september there was some discussion on overloading the new and delete
operators to be able to allocate memory from a shared arena. Jim Helman and
others gave a good explanation on this whole thing and also pointed out the
danger of using an overloading delete. The recommended way was to overload the
new and delete locally in each classes that need to be shared.

Personnaly I found the problem related to deleting 'newed' arrays with an
overloaded delete operator rather inconvenient.

In the release of Performer 2.0 does this still holds true or there is now
a way to avoid that problem?

To put things in perspective here is the original message of Jim Helman:

On Wed, 13 Sep 95 Jim Helman wrote:

> New and delete are a full three rings of fun.

> 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

-- 
     ___/     |       ___/ Nicolas Gauvin	   e-mail: nicolas++at++cae.ca
    /       / |      /     Software Developper	   voice: (514) 341-2000 x2275
   /       /  |     __/    CAE Electronics Ltd.    fax:   (514) 340-5496
  /       ___ |    /	   8585 Cote De Liesse, P.O. Box 1800
_____/  _/   _| _____/     Saint-Laurent, Quebec, Canada, H4L-4X4

New Message Reply Date view Thread view Subject view Author view

This archive was generated by hypermail 2.0b2 on Mon Aug 10 1998 - 17:52:09 PDT

This message has been cleansed for anti-spam protection. Replace '++at++' in any mail addresses with the '@' symbol.