By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
431,991 Members | 1,737 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 431,991 IT Pros & Developers. It's quick & easy.

designing a scalable storage

P: n/a
i need to create a storage module which can store any thing the user
wants. I want it to handle almost any storage requirement, so that
clients can define their own key classes derived from the base key
class which is defined by the storage module itself.

for example:
in the storage module we have
class base_key
{
public:
bool operator < (const base_key& rhs) const = 0;
}

class storage
{
public:
void store(base_key& key, void* data);
void* withdraw(base_key& key);
}

and in the client code,
class my_key : public base_key
{
public:
bool operator < (const base_key& rhs) const
{
...
}
}

i know the above code does not work. I managed to do allow that
functionality somehow by
using lot of workarounds for lot of problems, and that code works
well, but im not sure whether it is the
best method to do this. Im wondering whether there are any standard
methods to provide this kind of functionality, so i can compare my
implementation with it.

thanks.
Jun 27 '08 #1
Share this Question
Share on Google+
2 Replies


P: n/a
On May 20, 12:39*pm, e2po...@yahoo.com wrote:
i need to create a storage module which can store any thing the user
wants. I want it to handle almost any storage requirement, *so that
clients can define their own key classes derived from the base key
class which is defined by the storage module itself.
>
thanks.
struct base_key{
bool operator<(base_key const&r){
return less_than(r);
}
protected:
virtual bool less_than(base_key const&r)const=0;
};

struct mykey:base_key{

bool less_than(base_key const&r)const{
mykey const& R= dynamic_cast<mykey>(r);
return val<R.val;
}
private:
int val;

};
Lance
Jun 27 '08 #2

P: n/a
e2*****@yahoo.com wrote:
[..]
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
false.
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
implementation.
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
robust software.
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?

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
Jun 27 '08 #3

This discussion thread is closed

Replies have been disabled for this discussion.