NetNews Usenet Archive 1992 #26/NN_1992_26.iso/spool/comp/lang/cplus/16087

Internet Message Format | 1992-11-11 | 3.4 KB

Path: sparky!uunet!airgun!airgun.wg.waii.com!bab
From: [e-mail] (Brian Button)
Newsgroups: comp.lang.c++
Subject: Re: Discriminating Variant Records Without switch() ??
Message-ID: <[e-mail]>
Date: 11 Nov 92 12:54:54 GMT
References: <[e-mail]> <[e-mail]>
Sender: [e-mail]
Organization: Western Geophysical Exploration Products
Lines: 70
Nntp-Posting-Host: se39.wg2.waii.com
In-reply-to: [e-mail]'s message of 10 Nov 92 18:15:29 GMT


In article <[e-mail]>, [e-mail] (Brian Button) writes:
...
|> As an example:
|>
|> We're reading structures sent to us over a socket. Since these
|> structures are being sent and received on the same machine, we can
|> just memcpy the byte stream read from the socket into a big union, and
|> then switch based on the first field of the union to determine the type.
|>
|> As a trivial example:
|>
|> {
|>     read( sd, buf, 16 );
|>     memcpy(( char * )&union_of_structs, buf, 16 );
|>     switch( union_of_structs.type )
|>     {
|>         case A:
|>
|>             .
|>             .
|>             .
|>     }
|> }

   Glen> Well, this is a bit of a can of worms.

   Glen> It would seem to me that a solution to this problem would be a
   Glen> class dispatcher (or whatever you'd like to call it). Basically,
   Glen> the central entity is responsible for creating objects based on
   Glen> the data stream, having been given a list of tags and constructors
   Glen> to use for this purpose.

Basically, what you've described is a factory object. This object is
responsible for creating new instances of any arbitrary object, as
long as it is descended from some base class. In RogueWave, this class
is the RWCollectable, and the factory is an RWFactory.

Our problem, however, is not in the object creation, since the factory
can do that for us. Our problem is how to discriminate the type of the
object and process it accordingly after it is already created.

As an example, we're dealing with gyro-compasses, inclinometers, and
streamers. The first two objects are just data gathering devices, but
a streamer is a collection of instances of each of the previous
objects. Once we've created a streamer or a data gathering device
through this factory, they obviously need to be handled in different
ways. We may need to get the reading from a compass, reset its bias,
reposition it on the streamer, or get a list of all devices on the
streamer, find all compasses on the streamer, add a device to it, etc.
The point I'm trying to make is that there is no common set of
operations which may be performed on these arbitrary objects.

Since the set of operations is not common, we need to know the type of the
object before proceeding with processing. Have we painted ourselves
into a corner? It seems that we need a switch() to do this, but in a
proper OOP design, it shouldn't be necessary.

Advice??

bab

--
|-----------------------|----------------------------------------------------|
| Brian Button          | email : [e-mail]                        |
| Design Engineer       |         [e-mail]                   |
| Western Geophysical   | voice : [phone]                              |
| 3600 Briarpark        |----------------------------------------------------|
| Houston, Texas  77042 |                  Opinions Be Mine!!                |
|-----------------------|----------------------------------------------------|