|
-
January 16th, 2011, 07:49 PM
#1
Distributed enums
Hello, it's nice to be back 
I have a distributed system consisting of many processes, and I am designing a mechanism by which they can all send messages to a "monitor" process.
Each message consists of a code identifying the type of message, and a string containing the message contents. There are many types of messages (several for each type of process, and there are many types of processes). The purpose of encoding the message type in a code is so that the monitor can filter out certain types of messages and only show the rest.
My problem is where to declare the codes corresponding to the message types. Obviously I want them to be symbolic constants, not magic numbers, so an enumeration comes to mind. However, I don't want to have one central enumeration for all the message types, because I don't want to introduce gratuitous compile-time dependencies (since every component will include the header file that declares this enumeration, the build system will force all the components to be recompiled when I add a new message type for a new component).
So I'm trying to find a way to "distribute", i.e. spread out the enumeration so there's one piece for each component, and each component only needs its own piece. The obvious problem is how to come up with numerical starting values for the pieces, so that the numerical values of the symbols from different components do not overlap.
I can:
1) Assign the starting values manually. I don't want to do this because there are many components and it would be a maintenance headache.
2) Have a pre-build step that generates and assigns these starting values. I don't want to do this either because it would complicate the build process unnecessarily.
3) Automatically assign unique starting values at compile-time somehow. I'm trying to figure out a way to do this. Basically, I need to be able to generate a number that is unique to each file. I thought of trying to compute a compile-time hash of __FILE__, but that doesn't work (besides the fact that compile-time hashing is not even really possible without C++0x, there are multiple instances of each component that may be compiled on different machines, and __FILE__ may evaluate to a different string on different machines).
Any ideas about how I might be able to create such a "distributed enumeration"? I am open to new approaches to my original problem as well.
Old Unix programmers never die, they just mv to /dev/null
-
January 17th, 2011, 02:27 AM
#2
Re: Distributed enums
I used to have a situation where I had to have unique enumerations, but where the set of symbols were dependant on which modules were included in the application.
What I did then was to have an 'enum' header that got included in an enumeration definition.
Code:
enum
{
#include "enumerations1.enm"
#include "enumerations2.enm"
#include "enumerations3.enm"
};
"enumerations1.enm"
ONE,
TWO,
THREE,
"enumerations2.enm"
FOUR,
FIVE,
SIX,
"enumerations3.enm"
SEVEN,
EIGHT,
NINE,
That doesn't help of course if you want the same values across many applications.
"It doesn't matter how beautiful your theory is, it doesn't matter how smart you are. If it doesn't agree with experiment, it's wrong."
Richard P. Feynman
-
January 17th, 2011, 06:03 AM
#3
Re: Distributed enums
do you mean that each component has its unique set of messages ? if yes, then for each component you can write something like
Code:
// Comp1.h
class Comp1;
void PostMessage( const Comp1&, int msg );
class Comp1
{
enum Messages
{
msg1,msg2,
};
void SomeFunction() { PostMessage( *this, msg1 ); }
};
then, you can define those PostMessage overloads in a separate centralized cpp file ( maybe the "monitor" implementation ) where the message id is combined with a component id ( defined in the same cpp file ) to form the actual "raw" message code. In this way, adding a new component will recompile only the "monitor" code.
-
January 18th, 2011, 01:44 PM
#4
Re: Distributed enums
Two possible solutions to that:
(1) Using an additional enum with offsets
Code:
// eoff.h
enum
{
E1_OFF,
E2_OFF = 100,
E3_OFF = 200,
E4_OFF = 500,
...
};
// e1.h
#include "eoff.h"
enum
{
X = E1_OFF,
Y,
Z
};
// e2.h
#include "eoff.h"
enum
{
ONE = E2_OFF,
TWO,
THREE,
FOUR,
...
};
That way you only need full build when changing the eoff.h
(2) using class wrappers around the enums
Code:
// e1.h
struct E1
{
enum
{
X,
Y,
Z
};
};
// e2.h
struct E2
{
enum
{
ONE,
TWO,
THREE,
FOUR
};
};
You would address the constants by E1::X or E2::FOUR what might be inconvenient. However, if using many enumerations which necessarily need to have unique names, the name 'E1' (of course you should use a more senseful name) would work like a prefix what you probably would use for global enumerations as well.
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
|
Click Here to Expand Forum to Full Width
|