Smith, Jeff W. (jsmith++at++smtpgate.gstone.com)
Fri, 24 Feb 1995 16:00:13 -0800
The quick answer is: yes you can allocate C++ objects out of shmem. The
question you need to answer is, should you! Some issues to think about:
1. vtbls may not work correctly, that is, objects with virtual
methods become dangerous to use, because their
table look-ups might point to different address spaces
2 If you still want to allocate objects out of shmem, then overload
the new operator and use shmem for allocating the memory
to use. This way the compiler will add the proper constructor
call so to a user of yoour class, everything appears the same.
Just use new and delete as usually for that particular class.
Remember, however, to also overload delete when you
overload new.
3. A more common approach is to just allocate your object's
data from shmem.
-- Jeff WS
jsmith++at++gstone.com
----------
From: Lance R. Marrou
To: Performer List
Subject: shared memory object classes
Date: Friday, February 24, 1995 1:33PM
I am curious if it is possible to use the operator new to allocate an object
class in shared memory. I tried most (if not all) combinations like:
po = ::new(sizeof(printobj),pfGetSharedArena()) printobj();
po = new(sizeof(printobj),pfGetSharedArena()) printobj();
po = new(pfGetSharedArena()) printobj();
These were just some simple test cases, I have much more complicated classes
in mind. What seems to work is this:
po = (printobj *)pfMalloc(sizeof(printobj),pfGetSharedArena());
But then I need a fake constructor to call after allocation.
____________________________________________________________________________
__
/\ ______ /\____ ______ ______ E-mail:
marrou++at++vsl.ist.ucf.edu
Visual / / / _ / / __ // ____// ____/ VSL:
(407)658-5073
Systems / /__ / /_/ / / / / // /___ / __/_ R. Marrou Fax:
(407)658-5059
Lab /____//____/\\/_/ /_//_____//_____/
http://www.vsl.ist.ucf.edu/~marrou
"Reap the whirlwind." "We don't need no thought
control."
------ Message Header Follows ------
Received: from realityone.gstone.com by smtpgate.gstone.com
(PostalUnion/SMTP(tm) v2.1.3 for Windows NT(tm))
id AA-1995Feb24.133319.1024.2147; Fri, 24 Feb 1995 13:33:19 -0800
Received: from SGI.COM by realityone.gstone.com via SMTP
(931110.SGI/930416.SGI.AUTO)
for jsmith++at++smtpgate.gstone.com id AA25259; Fri, 24 Feb 95 13:33:15
-0800
Received: from holodeck.asd.sgi.com by sgi.sgi.com via ESMTP
(950221.405.SGI.8.6.10/910110.SGI)
id NAA14248; Fri, 24 Feb 1995 13:22:57 -0800
Received: by holodeck.asd.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO)
for info-performer-dist id MAA29687; Fri, 24 Feb 1995 12:47:32 -0800
Received: from giraffe.asd.sgi.com by holodeck.asd.sgi.com via SMTP
(940816.SGI.8.6.9/940406.SGI.AUTO)
for <info-performer++at++holodeck.asd.sgi.com> id MAA29684; Fri, 24 Feb 1995
12:47:20 -0800
Received: from sgi.sgi.com by giraffe.asd.sgi.com via SMTP
(920330.SGI/920502.SGI)
for info-performer++at++holodeck.asd.sgi.com id AA02815; Fri, 24 Feb 95
12:46:58
-0800
Received: from vsl.ist.ucf.edu by sgi.sgi.com via SMTP
(950221.405.SGI.8.6.10/910110.SGI)
for <info-performer++at++sgi.com> id MAA09520; Fri, 24 Feb 1995 12:46:54
-0800
Received: from grail.vsl.ist.ucf.edu by vsl.ist.ucf.edu (4.1/SMI-4.1)
id AA02944; Fri, 24 Feb 95 15:48:28 EST
Received: by grail.vsl.ist.ucf.edu (940816.SGI.8.6.9) id PAA24805; Fri, 24
Feb
1995 15:47:22 -0500
Date: Fri, 24 Feb 1995 15:47:21 -0500 (EST)
From: "Lance R. Marrou" <marrou++at++vsl.ist.ucf.edu>
To: Performer List <info-performer++at++sgi.com>
Subject: shared memory object classes
Message-Id: <Pine.SGI.3.91.950224153017.24528A-100000++at++grail.vsl.ist.ucf.edu>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
This archive was generated by hypermail 2.0b2 on Mon Aug 10 1998 - 17:51:00 PDT