Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!rutgers!bellcore!faline!thumper!ulysses!andante!alice!shopiro
From: shopiro@alice.UUCP (Jonathan Shopiro)
Newsgroups: comp.lang.c++
Subject: Re: Objects and Shared Memory
Summary: Use a surrogate object to represent shared memory
Message-ID: <9171@alice.UUCP>
Date: 10 Apr 89 01:12:09 GMT
References: <5462@cbnews.ATT.COM>
Organization: AT&T Bell Laboratories, Murray Hill NJ
Lines: 36



I think the best way to deal with data in shared memory is with
what I like to call ``surrogates.''  For example, you might have

	class Actual_shared_data {	// this is an object in shared memory
	friend class Shared_data;
		// only data members here
		// no public data or functions at all
	};
	class Shared_data {	// this is the surrogate
		Actual_shared_data*	p;
	public:
		Shared_data();	// constructor
		// the public interface goes here
	};

Then the constructor Shared_data::Shared_data() is in charge of
allocating shared memory, or of finding the address of the appropriate
shared memory object.  Note that whenever you say ``new Shared_data''
you get a new Shared_data object, even if it points to an old block of
shared memory.  Storage management schemes that violate this rule are
unlikely to win.

If you can't have real pointers in shared memory because of address
mapping considerations, it is simple to put whatever transformations
are necessary between the data in Actual_shared_data and regular
pointers into access functions in Shared_data.  Shared_data can also
have whatever virtual functions are appropriate.  In exchange for
an extra level of indirection (which you would be likely to need anyway)
you can encapsulate all the complexity of dealing with shared memory
in Shared_data, which the user treats like any other object.
-- 
		Jonathan Shopiro
		AT&T Bell Laboratories, Warren, NJ  07060-0908
		research!shopiro   (201) 580-4229