Account Options

  1. Sign in
The old Google Groups will be going away soon, but your browser is incompatible with the new version.
Google Groups Home
« Groups Home
Message from discussion Mapping operations to codes
The group you are posting to is a Usenet group. Messages posted to this group will make your email address visible to anyone on the Internet.
Your reply message has not been sent.
Your post was successful
 
From:
To:
Cc:
Followup To:
Add Cc | Add Followup-to | Edit Subject
Subject:
Validation:
For verification purposes please type the characters you see in the picture below or the numbers you hear by clicking the accessibility icon. Listen and type the numbers you hear
 
Victor Bazarov  
View profile  
 More options Aug 23 2011, 4:23 pm
Newsgroups: comp.lang.c++
From: Victor Bazarov <v.baza...@comcast.invalid>
Date: Tue, 23 Aug 2011 16:23:47 -0400
Local: Tues, Aug 23 2011 4:23 pm
Subject: Re: Mapping operations to codes
On 8/23/2011 3:30 PM, Default User wrote:

> "Victor Bazarov"<v.baza...@comcast.invalid>  wrote in message
> news:j30pb0$1pi$1@dont-email.me...
>> The maps don't seem to be needed per instance of class ('test') but rather
>> per class (i.e. they should probably be static).  That's all I have so
>> far.  I would probably try rewriting the code so that 'write' and 'list'
>> functions were static as well.

> I fear I haven't given enough information, and my example was too sketchy.

> 1. There will be a number of different drivers, one for each instrument, all
> of with derive from the base class.

That's your design.  That's not the problem definition, though.

> 2. The driver objects will be contained by other, higher-level ones. These
> higher level "device" modules are derived from a common base class
> themselves.

OK.  A device consists of (or contains) a collection of drivers.  Let's
go with that.

 > That base class has a pointer to the driver base class.

A *single* pointer?  How does that work with the collection (see above)?

 > The

> derived class objects will populate that pointer with the particular driver
> that they need.

A single pointer?  Is that some kind of an "active" driver?  From where
do those get populated?  Is there a repository of driver objects?

> 3. The "device" objects will call the small set of public methods using
> polymorphism.

Whose methods?  Driver's?

 > Some methods are in the base class, others specific to a

> particular device. Mostly these route op codes and data to the driver, or
> retrieve data pulled from the instrument.

"The" instrument?  The "active" one?  There is only one instrument at a
time?  Can there be the need to retrieve data from a driver/instrument
that is not active?

> 4. The drivers will have class attributes that contain state information
> about the particular instrument associated with the driver. The op code
> handlers can't be static. Here my example really failed. Mentally add
> several attributes, if you would.

You're explaining your design instead of explaining the problem.  Can
one device have drivers that serve the same operation?  If not, then
each driver (op server or whatever you decide to call it) is unique at
the *device* level, and there seems to be no sense to map its operation
to its function at the level of the *driver*.  Place a master map at the
device level.

V
--
I do not respond to top-posted replies, please don't ask


 
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.