[comp.lang.c++] Virtual Functions in IPC environment

mark@lznv.ATT.COM (MARK SMITH) (08/31/87)

I am building a message-based system consisting of client/server processes
which I would like to implement using C++.  As such, for a given message
I would like to define the base class

class MsgHdr { IPC private data items; public: IPC access functions(); };

and a set of derived classes

class DerivedN: public MsgHdr {
	private data for DerivedN;
public:
	virtual void Operate();		// server: do DerivedN-specific fct
};

However, I encounter two difficulties:

(1) Although the intention is clearly to allow Operate() only to be
usable by the server, I can't find a way to disallow a client process from
linking with Operate.  Since I am memory-conscious (I'm using swapping UNIX), 
this is a critical fault.

(2) Similarly, the client can't send a DerivedN and expect Operate to work, 
since the server gets a DerivedN Operate linked in the address space
of the client.  Memory fault core dumped.

Is there some better abstraction?  I came up with some ugly (more C-like)
workarounds involving run-time virtual function linking (for (1)) 
and readdressing (for (2)).  Shared libraries are out, too.
I'm beginning to believe there's no advantage in using C++ objects if
they are to be passed across process boundaries.

Mark Smith --- { all that jazz } ! lznv ! mark

keith@nih-csl.UUCP (keith gorlen) (09/03/87)

In article <1120@lznv.ATT.COM->, mark@lznv.ATT.COM (MARK SMITH) writes:
-> 
-> I am building a message-based system consisting of client/server processes
-> which I would like to implement using C++.  As such, for a given message
-> I would like to define the base class
-> 
-> class MsgHdr { IPC private data items; public: IPC access functions(); };
-> 
-> and a set of derived classes
-> 
-> class DerivedN: public MsgHdr {
-> 	private data for DerivedN;
-> public:
-> 	virtual void Operate();		// server: do DerivedN-specific fct
-> };
-> 
-> However, I encounter two difficulties:
-> 
-> (1) Although the intention is clearly to allow Operate() only to be
-> usable by the server, I can't find a way to disallow a client process from
-> linking with Operate.  Since I am memory-conscious (I'm using swapping UNIX), 
An easy way around this is to define a dummy version of Operate that just
issues an error message and link this with clients instead of the real Operate.

-> (2) Similarly, the client can't send a DerivedN and expect Operate to work, 
-> since the server gets a DerivedN Operate linked in the address space
-> of the client.  Memory fault core dumped.

My Object-Oriented Program Support (OOPS) class library implements a
general mechanism similar to Smalltalk's storeOn/readFrom that permits
OOPS objects to be moved across process boundaries

To get a copy of the "guru-only" version of OOPS, just send me a
letter on your company or university letterhead requesting the
"Object-Oriented Program Support (OOPS) class library for C++" and a
reel of 1/2" mag tape (a small reel will suffice).  I'll return the
tape with a copy of OOPS recorded on it in tar format at 1600 bpi, and
I'll include a copy of the (incomplete) OOPS reference manual.

Please include your uucp address in the letter.
-- 
	Keith Gorlen			phone: (301) 496-5363
	Building 12A, Room 2017		uucp: seismo!elsie!nih-csl!keith
	National Institutes of Health
	Bethesda, MD 20892