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
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 That's your design. That's not the problem definition, though. > 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 > 2. The driver objects will be contained by other, higher-level ones. These OK. A device consists of (or contains) a collection of drivers. Let's > higher level "device" modules are derived from a common base class > themselves. 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 A single pointer? Is that some kind of an "active" driver? From where > that they need. do those get populated? Is there a repository of driver objects? > 3. The "device" objects will call the small set of public methods using Whose methods? Driver's? > polymorphism. > Some methods are in the base class, others specific to a > particular device. Mostly these route op codes and data to the driver, or "The" instrument? The "active" one? There is only one instrument at a > retrieve data pulled from the instrument. 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 You're explaining your design instead of explaining the problem. Can > 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. 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 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.
| ||||||||||||||