Re: Overloading the 'new' operator

New Message Reply Date view Thread view Subject view Author view

Jim Helman (jimh++at++surreal)
Tue, 30 May 95 22:38:04 -0700

There shouldn't be any problem overloading the new operator to define
a version that uses pfMalloc and the shared arena for creating your
objects. The only issues I'm aware of have to do with pointers that
might only be valid in one process. Most pointers are explicit, so
making sure everything refers to shared memory is your problem. But
if you use virtual functions you could run into problems with them.
In particular, if you dynamically load in (e.g. via a DSO) the class,
you need to do so in all processes, and the virtual function tables or
functions could end up at different locations in different processes.
However, this won't happen with statically linked objects or with DSOs
loaded before pfConfig. Even those loaded after pfConfig will
probably wind up at the same location unless a conflict arises.

I'm not sure why you are having problems since the same should be
possible using a usinit arena (although a usinit arena is only
*required* between unrelated processes and takes some care in
positioning with usconfig(CONF_ATTACHADDR,...) to avoid virtual
memory conflicts). This latter could be causing your problems.

Performer has always used an overloaded new() operator for allocating
libpf objects. In 1.2, this operator is a global new() operator with
a private second argument type to keep it internal and separate from
any application's usage or overloading of new. In 2.0, this has been
changed so that libpf objects are newed using an class-specific new()
function overloaded as appropriate within the libpr/libpf class
hierarchy.

rgds,

-jim helman

jimh++at++surreal.asd.sgi.com
415/390-1151

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:51:33 PDT

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