Re: Overloading the 'new' operator

New Message Reply Date view Thread view Subject view Author view

Michael J. Smith (smith++at++vsl.ist.ucf.edu)
Tue, 30 May 1995 22:29:48 -0400 (EDT)


On Tue, 30 May 1995, Kent Miller wrote:

> I realize that this discussion already took place here (maybe 2 mos
> back), but I need a refresher.
>
> I'm pretty sure I want to create new objects from the shared arena, but
> I seem to remember some objections to this approach.

As I remember there were objections about the C++ virtual table not being
correctly represented for calls from multiple execution threads. Does
anyone have any hard evidence and can pinpoint where this becomes a problem?

> Would someone summarize for me the pros & cons of overloading new to
> use the shared arena, and perhaps a brief example?

I was looking into this recently, and found that using the IRIX REACT
system such as usinit, and usadd, along with usmalloc, and usfree would
allow me to use my C++ data-structures in a shared memory space. This
allows for me to use really nice data-structures among multiple processes
-- so I would love to be able to do this.

However, when I tried to integrate this exciting potential into my
performer application I was firmly rejected in all attempts. I basically
tried to overload the new and delete operators to provide a global use of
the shared arena I had chosen. This works in test applications as long as
I make sure that I initialize the arena before using the functions.

So, the problem now is I can't use a separate arena in the performer app
because it conflicts with performers arena that is attached to the user
memory segment. When I try to use my overloaded new and delete
operators (which just call usmalloc and usfree), this causes the perf
library to seg fault down in a call to _grow or something like this. If
this sounds like an interesting subject I can get more details on what
the errors were exactly, but their exact nature seemed expected and easy
to cause.

If there is a way I can (without making a lot of ugly code additions) add
the functionality of new'ing objects into the shared seg under performer
I would love to hear about successes. I remember someone suggested
possibilities about 2 months ago as to what could be done to overload the
new and delete operators, but when I tried this method it didn't work for me.

The best of all worlds would be to hear that I can overload the global
new and delete functions in a specific way to support performers internal
libraries and still allocate all of my objects into the shared segment.

Thanks for any suggestions and information...

-----------------------------------------------------------------------------
| Michael J. Smith University Of Central Florida |
| Visual Systems Laboratory Institute for Simulation & Training |
| Graduate Research Assistant 3280 Progress Drive |
| smith++at++vsl.ist.ucf.edu Orlando, FL 32826-0544 |
| ++at++cs.ucf.edu |
| Codesmith for hire |
-----------------------------------------------------------------------------


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.