NetNews Usenet Archive 1993 #3/NN_1993_3.iso/spool/comp/lang/cplus/20056

Internet Message Format | 1993-01-25 | 3.4 KB

Xref: sparky comp.lang.c++:20056 comp.std.c++:2139
Path: sparky!uunet!cimshop!davidm
From: [e-mail] (David S. Masterson)
Newsgroups: comp.lang.c++,comp.std.c++
Subject: Re: Callbacks -- suggested approaches??
Message-ID: <[e-mail]>
Date: 28 Jan 93 18:58:05 GMT
References: <[e-mail]> <rmartin.728090477@stripe>
Sender: [e-mail]
Organization: Consilium Inc., Mountain View, California
Lines: 50
In-reply-to: [e-mail]'s message of 26 Jan 93 23:21:17 GMT
X-Posting-Software: GNUS 3.13  [ NNTP-based News Reader for GNU Emacs ]

>>>>> On 26 Jan 93 23:21:17 GMT, [e-mail] (Bob Martin) said:

> Given that class A wants to send the message X to class B.

> Unfortunately, theB lives in another process.  No problem.  Create an
> abstract class called AbstractB.  It contains a set of pure virtual
> functions defining all the messages that B can receive.  B will
> inherit from AbstractB.  So will another class called BSurrogate.
> BSurrogate knows which process the real B object lives in and knows
> how to convert the message into a packet and ship it to that process.
> The packet will contain all the arguments to X, an identifier denoting
> that it represents an X message and the identifier of the B object to
> which the message should be sent.

> When the process receives the it looks up the name of the object in a
> dictionary.  The dictionary associates the name with a derivative of
> the class Reciever.  BReceiver is derived from Receiver, and knows how
> to unpack the X packet.  It also knows where the B object is (Probably
> it contains a pointer to it), so it unpacks all the arguments and then
> sends the message to its B object.

> Return values can be passed back by the same route by simply having
> the Surrogate add a return address onto the packet.

In a sense, this is what we've done -- our modelling is somewhat different
than your's, though.  The best way I could think of describing the difference
between your model and our model is to look at the IOStream library.  In the
model you describe above, you are basically defining the user interface for
the B::operator<< while we are describing the definition of an Ostream that
will carry the data that operator<< builds to its intended destination.  The
next level (or layer) in our system is really the same as your description.

The problem in what you describe is still one of dispatching the message
received by a process to the appropriate object that will handle the message.
The issue is what does the dictionary look like and how does the process read
it and know what to call.  Here you must assume that the number of messages
that the dictionary can interpret is sufficiently large and diverse (ie. not
all the same type) in order to make the solution interesting.  For the most
part, the question is one of syntax allowed by C++ (ie. what's the most
type-safe way of doing it?) rather than one of modelling (there are many
models that may be chosen).
--
====================================================================
David Masterson                    Consilium, Inc.
[phone]                    640 Clyde Ct.
[e-mail]                Mtn. View, CA  94043
====================================================================
"I'll put an end to the idea that a woman's body belongs to her . . . the
 practice of abortion shall be exterminated with a strong hand."
-- Adolf Hitler, _Mein Kampf_