Multi-type Containers

[Barzo]

Hi,

I have to manage a class of messages.
Instead of create a type for each message, I've thought something like
this:

struct message{
int OP_CODE;
t_param params;
}

Where t_param should be an heterogeneous container (eg. vector).
Searching around I've found the boos::extension type_map.

Is this a good solution or is there a better "coding style" for this
problem?

Thanks!
Daniele.

 

[Alf P. Steinbach]

* Barzo:

Hi,

I have to manage a class of messages.
Instead of create a type for each message, I've thought something like
this:

struct message{
int OP_CODE;
t_param params;
}

Where t_param should be an heterogeneous container (eg. vector).
Searching around I've found the boos::extension type_map.

Is this a good solution or is there a better "coding style" for this
problem?

Depends entirely on the dog. That is, the number of tails it has depends, as
Niels Bohr once remarked. The solution you've outlined is used e.g. at the low
level Windows API level. Consider that there are a phletora of higher level
wrappers for that level. What's an appropriate level depends on what one is doing.

The above seems to mix two levels: it's not usable from C, and it doesn't take
advantage of C++ typing.

But (except for the use of all uppercase) it could still be appropriate for
whatever it is you're doing.


Cheers & hth.,

- Alf

 

[Barzo]

Depends entirely on the dog. That is, the number of tails it has depends, as
Niels Bohr once remarked.

- Alf

I understand the antiphon! ;-)

What exactly I have to do is building an AT command dispatcher class,
and for every AT command I should create a type containing the command
details, that's it.

Thanks!
Daniele.

 

[Alf P. Steinbach]

* Barzo:

I understand the antiphon! ;-)

What exactly I have to do is building an AT command dispatcher class,
and for every AT command I should create a type containing the command
details, that's it.

OK.

Assuming "AT" refers to modem commands, and not e.g. the Windows "AT" command
which now is sort of deprecated in favor of a newer more complicated scheme (it
was too simple and practical, actually useful):

I think I would focus on dividing things into two levels: the level of logical
actions (send text, wait x seconds, wait for response "xyz", reinitialize, and
so on) and the level of logical AT commands. A logical AT command such as "dial
number nnnnnnn" will generally result in a sequence of actions involving e.g.
waits, and it may be necessary to have those actions configurable per command.

To support an open-ended set of commands -- not all modems use the Hayes AT
command set, and most add extensions -- I think the most general and practical
representation of the text parts (e.g. command id) is as pure text, not as
numerical id's.

Disclaimer: I haven't done this, but OTOH I have scripted many a modem, and that
experience to some degree stands in for domain knowledge acquisition that you'll
have to do in order to design that fits well with reality.


Cheers & hth.,

- Alf


PS: Do what you feel is Right regardless of above advice, which may be very wide
off the mark.

And PPS: This question is probably better asked in e.g. [comp.programming].

 

[Barzo]

Assuming "AT" refers to modem commands

Yes, it is!

I think I would focus on dividing things into two levels: the level of logical
actions (send text, wait x seconds, wait for response "xyz", reinitialize, and
so on) and the level of logical AT commands.

This is what exactly what I'm trying to do.
I'm trying to build a library to manage different kinds of modems, and
now I'm at the point of two level separation (or interaction).
So I have to decide if to add another little layer (that abstracts the
"command" concept) between the two levels or let each "specific modem
class" to manage its AT Commands, talking directly to logical level.
I do not know if I have explained well..

I think the most general and practical representation of the text parts (e.g. command id) is as pure text, not as numerical id's.

I agree!

And PPS: This question is probably better asked in e.g. [comp.programming].

Yes, at this stage I think so!


Thanks a lot Alf!
Daniele.