designing a scalable storage

E

e2point

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.
 
L

Lance Diduck

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.

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
 
E

e2point

In order to be able to declare it pure, you need to declare it virtual
first.


You've missed a semicolon here.




I would strongly recommend changing the first arguments to 'base_key
const &' (since it's unlikely to change the arguments).


Another missing semicolon...




Again, a semicolon is missing.

And how does the client use your "scalable storage"? What's so scalable
about it?


I don't know that. You didn't specify what "work" means. Do you mean
the syntax errors like declaring a non-virtual function pure?



What kind of problems?



To do what, exactly? Store almost anything?



What kind of functionality do you mean? Storing void pointers in a map
is what you seem to be doing. Does that constitute "storing almost
anything"? I doubt it since your container isn't really storing
anything except the addresses. The actual objects must be stored
elsewhere. Not sure how you could use the term "scalable" here (and
what it actually means)...

Take a look at 'boost::any' class. It's compatible with standard
containers (and akin to Msoft's VARIANT, I believe). Beyond that you
need to state your requirements (and your users' requirements) to ask
your questions. "Store any thing" is not a requirement, really. Well,
it is a requirement, it's just not a good one.

V

i know my post is't very clear, but
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.
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.
 
E

e2point

In order to be able to declare it pure, you need to declare it virtual
first.


You've missed a semicolon here.




I would strongly recommend changing the first arguments to 'base_key
const &' (since it's unlikely to change the arguments).


Another missing semicolon...




Again, a semicolon is missing.

And how does the client use your "scalable storage"? What's so scalable
about it?


I don't know that. You didn't specify what "work" means. Do you mean
the syntax errors like declaring a non-virtual function pure?



What kind of problems?



To do what, exactly? Store almost anything?



What kind of functionality do you mean? Storing void pointers in a map
is what you seem to be doing. Does that constitute "storing almost
anything"? I doubt it since your container isn't really storing
anything except the addresses. The actual objects must be stored
elsewhere. Not sure how you could use the term "scalable" here (and
what it actually means)...

Take a look at 'boost::any' class. It's compatible with standard
containers (and akin to Msoft's VARIANT, I believe). Beyond that you
need to state your requirements (and your users' requirements) to ask
your questions. "Store any thing" is not a requirement, really. Well,
it is a requirement, it's just not a good one.

V

i know my post is't very clear, but
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.
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.
 
E

e2point

In order to be able to declare it pure, you need to declare it virtual
first.


You've missed a semicolon here.




I would strongly recommend changing the first arguments to 'base_key
const &' (since it's unlikely to change the arguments).


Another missing semicolon...




Again, a semicolon is missing.

And how does the client use your "scalable storage"? What's so scalable
about it?


I don't know that. You didn't specify what "work" means. Do you mean
the syntax errors like declaring a non-virtual function pure?



What kind of problems?



To do what, exactly? Store almost anything?



What kind of functionality do you mean? Storing void pointers in a map
is what you seem to be doing. Does that constitute "storing almost
anything"? I doubt it since your container isn't really storing
anything except the addresses. The actual objects must be stored
elsewhere. Not sure how you could use the term "scalable" here (and
what it actually means)...

Take a look at 'boost::any' class. It's compatible with standard
containers (and akin to Msoft's VARIANT, I believe). Beyond that you
need to state your requirements (and your users' requirements) to ask
your questions. "Store any thing" is not a requirement, really. Well,
it is a requirement, it's just not a good one.

V

i know my post is't very clear, but
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.
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.
 
E

e2point

In order to be able to declare it pure, you need to declare it virtual
first.


You've missed a semicolon here.




I would strongly recommend changing the first arguments to 'base_key
const &' (since it's unlikely to change the arguments).


Another missing semicolon...




Again, a semicolon is missing.

And how does the client use your "scalable storage"? What's so scalable
about it?


I don't know that. You didn't specify what "work" means. Do you mean
the syntax errors like declaring a non-virtual function pure?



What kind of problems?



To do what, exactly? Store almost anything?



What kind of functionality do you mean? Storing void pointers in a map
is what you seem to be doing. Does that constitute "storing almost
anything"? I doubt it since your container isn't really storing
anything except the addresses. The actual objects must be stored
elsewhere. Not sure how you could use the term "scalable" here (and
what it actually means)...

Take a look at 'boost::any' class. It's compatible with standard
containers (and akin to Msoft's VARIANT, I believe). Beyond that you
need to state your requirements (and your users' requirements) to ask
your questions. "Store any thing" is not a requirement, really. Well,
it is a requirement, it's just not a good one.

V

i know my post is't very clear, but
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.
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.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,968
Messages
2,570,149
Members
46,695
Latest member
StanleyDri

Latest Threads

Top