I am not sure if I understand the complete requirements, but from my
understanding...
If you guarantee that the module name will be unique, you can hash the
module name at the compile time using templates and use that as ID. A
good hashing algorithm guarantees unique hash value so that should
ensure that the ID remains unique. Let me know if you need any help in
this.
If the module at the client side has to communicate with same module
at server side, hand-shake is mandatory. You might want to share
version info of the module or some other such information that is
required in further communication. So, why don't you let the server
assign ID? Client never assigns ID for modules which have
corresponding server modules, it registers the module with the server
[or otherwise] and requests the server to assign ID. If there is no
corresponding server side module, then client can assign its own ID.
Something like - all the server assigned ID's will have most
significant bit set while the client side ID's won't. That way they
won't conflict.
On Mar 27, 2010, at 9:48 AM, Manohar Vanga wrote:
Note: I leave it to the module programmers to worry about creating
unique ID's for now.
Thanks
Manohar
On Sat, Mar 27, 2010 at 5:17 AM, Manohar Vanga <[email protected]
> wrote:
The problem is that the application is based on a client-server
model. The modules are loaded on both sides and communicate with
each others counterpart on the other end. The messages are routed to
the correct module based on the module ID stored in the packet. Thus
it needs to be done at compile time itself so the client and server
can share the values.
Another way is to generate a map of (server_side_ID --> module_name)
on the server and send the map to the client before communication
begins. The client can then use it to generate a (server_side_ID -->
client_side_ID) map. This work but adds a horrible overhead (no
matter how efficiently it is implemented) as the map will need
consulting for every received packet. Quite unnecessary overhead
IMO. At least if it can be done somehow at compile time.
Any other ideas? :P
Thanks
Manohar
---------- Forwarded message ----------
From: Coder Bean <[email protected]>
Date: Sat, Mar 27, 2010 at 4:56 AM
Subject: Re: [twincling] Recursive Preprocessing?
To: [email protected]
What you are trying to do is essentially what all the component
based framework's tried to achieve using UUID. However, IMHO, just
checking whether the id is not zero cannot ensure that the modules
don't have invalid ID. As two modules can be built with same id, in
that case. If you want the ID's to be unique per session, you might
want the host application to generate the ID's and assign it to each
module.
On Sat, Mar 27, 2010 at 6:52 AM, Manohar Vanga <[email protected]
> wrote:
It is C++. I can use templates (although I would prefer to steer
clear of it for the time being).
The problem is that I have written piece of code that dynamically
loads shared libraries at run time (dlopen/dlclose/dlsym). Each
module must have a unique ID and it needs to be checked for a
correct value (!=0). I do this at load time as well, but it would be
great if there was a way to do the checks at module compile time so
people know of invalid ID's before the time of loading.
For now, I have written a small preprocessor which is "checking" the
module for correctness. Not the prettiest thing in the world, but it
works.
Thanks
Manohar
On Fri, Mar 26, 2010 at 5:29 PM, coderbean <[email protected]>
wrote:
On Mar 25, 2010, at 10:42 AM, Manohar Vanga wrote:
Does anyone know if the following code can be made to work?
Alternative would also be appreciated:
#define INIT_MODULE(id) \
#if (id == 0)\
#error "Invalid ID"\
#else\
#define __MODULE_ID__\
int __module_id = id;\
#endif
The __MODULE_ID__ is required later on in the preprocessing. Any
suggestions? I would hate to have to sit and write my own
preprocessor :-/
Can you please tell what exactly you are trying to achieve here? Is
this C or C++? Can you use templates instead of preprocessor?
Thanks
Manohar
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
