- Forum
- General C++ Programming
- Best approach for dealing with unavoidab
Best approach for dealing with unavoidable duplicate keys in a hash table?
The project I am currently working on is an engine that needs to deal with a large number of plugins, including those built by other parties. I need an object manager that provides quick access to objects provided by those plugins. This is in part because the application needs to provide both script and xml based access to those objects. It should be noted that multiple plugins can be loaded at the same time.
It is my understanding that a hash table so that objects can be found easily by using their name is the best way to approach this. The problem is that there is no way to guarantee that two objects from different modules won't have the same name.
I have come up with two approaches to the problem and I want to find the solution that is most efficient. If anyone can provide any insight it would be much appreciated.
Option 1: create a hash table for each plugin and resolve object requests by using two lookups - one to find the module, the second to find the object.
Option 2: create a custom hash table that allows duplicate names and just make sure we also have the correct module id.
Are there any other options? Any insight on which would provide the most efficient approach? I am leaning toward option 2 but I am not 100% sure I will be using the best hash table design.
It is my understanding that a hash table so that objects can be found easily by using their name is the best way to approach this. The problem is that there is no way to guarantee that two objects from different modules won't have the same name.
I have come up with two approaches to the problem and I want to find the solution that is most efficient. If anyone can provide any insight it would be much appreciated.
Option 1: create a hash table for each plugin and resolve object requests by using two lookups - one to find the module, the second to find the object.
Option 2: create a custom hash table that allows duplicate names and just make sure we also have the correct module id.
Are there any other options? Any insight on which would provide the most efficient approach? I am leaning toward option 2 but I am not 100% sure I will be using the best hash table design.
Last edited on
Why don't you add the module name to the plugin name, this should give a unique key for a std::map.
I thought of doing that Thomas and it is a possibility I could use. I just wanted to avoid it because the extra time needed to process (hash) the extra string length might make it faster to do another way.
I am actually thinking of using a different method that I thought of after I raised the question:
Most of the objects will only be accessed from within their own module. Only rarely will a lookup be done for an object in another module. So what I am probably going to do is have a base class that contains a reference/pointer to the owning module's manager so that most object look-ups only require one lookup (unless the object is external... on that rare occasion).
Any object that is supposed to lookup other objects will inherit the above base class and it will be supplied to the lookup engine.
I am actually thinking of using a different method that I thought of after I raised the question:
Most of the objects will only be accessed from within their own module. Only rarely will a lookup be done for an object in another module. So what I am probably going to do is have a base class that contains a reference/pointer to the owning module's manager so that most object look-ups only require one lookup (unless the object is external... on that rare occasion).
Any object that is supposed to lookup other objects will inherit the above base class and it will be supplied to the lookup engine.
Last edited on
Topic archived. No new replies allowed.