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