Re: designing a scalable storage
Lance Diduck managed to infer the meaning of it and propose a
technique i can use to implement what i want. However it has some
problems when we compare two different types of keys. In the above
implementation, dynamic_cast will return NULL, if the cast is invalid.
What to do then? we cant just fail, we need to return either true or
See, you're asking us to define your class behaviour. We can't. We
don't know the problem domain. In most cases if the two classes have
the same base class (siblings, so to speak) but both have data in
addition to the base class subobject, comparing them makes simply no
sense. In which case they shouldn't be allowed to serve as the sorting
attribute for any data. I believe that's the design flaw in your
scheme, and you need to overcome this before you can proceed to the
To overcome this, i added an interger that identified the key class
type, and in the base class '<' operator, i can check for this
interger, and if they are equal call less_than, and if not return
something based on that interger. This works fine, but im not 100%
satisfied, as i think this kind of workarounds are not acceptable in
therefore im planning to go for a template based solution for this.
I think you're not seeing the big picture. If you need storage that
works fast, you should use a hash table and let your clients' objects
define a hash code calculation but that hash code has to be of a fixed
type. You've come up with an integer. Is that enough? I don't know.
It seems that you're still on the fence. You want to provide the
clients with a way to store their data with a polymorphic key, but at
the same time your comparison requirement takes all the wind out of the
original idea (that would keep the key polymorphic) and instead you need
your key to be specific.
Now, how can templates help you? With templates if your clients will
provide the type of the key and its comparison function (or whatever
that would help sorting the keys), but you won't be able to put
different types from different clients in the same efficient storage,
they would need to be separate types. Now, wrap 'std::map<T, void*>',
provide the user with the ability to pick T, and you're done! Or are you?
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask