Thread: How to store a huge list of switch-case like pairs in secondary memory ?

I'm trying to make a console shell for a simple virtual machine I'm making.

When the shell receives a command, It should call the corresponding function with all the arguments provided with (-option_name argument) syntax.
But I realized that the list of those functions will grow over time.
Is there any way store the whole database, such that given the primary key (the command) it would know how to call the corresponding function..?

I tried to use the STL types like map and set, but could only use them to store the nascent thing in ram...

Originally Posted by Salem

A map like this perhaps?

Code:

#include<iostream>
#include<iomanip>
#include<map>
using namespace std;

void doThis ( void ) {
  cout << "this" << endl;
}
void doThat ( void ) {
  cout << "that" << endl;
}
typedef void (*fn)(void);

int main(){
  map<string,fn> commands;
  commands["this"] = doThis;
  commands["that"] = doThat;
  commands["this"]();
  return 0;
}

I was thinking of putting the whole thing in a disk, but realized that it'd be foolish to hard code function pointers..
Anyway; putting a ..say.. 10 Mb map into ram would be faster that looking it up on the hard disk every time a command is encountered..

err...I am still in high school, and would implement everything I learn about computers, operating systems, etc.. on my virtual machine...for the next decade or so.! So, I think 10 Mb is a safe bet.

Do you know how much code that is?

Assuming about 2 instructions average per line of C code, and an average instruction opcode size of 16-bit (I actually don't know about this one), that's 4 bytes per line of C code.

10MB (assuming you actually meant bytes instead of bits) would be about 2.5 million lines of code.

Assuming an average speed of 200 lines per day, that's about 12500 days, or about 35 years if you code every single day, give or take an order of magnitude.

I really don't think this project will interest you for that long...

Comments would add another few years depending on how verbose they get.

By the way, function pointers should never be stored across program instances. You aren't guaranteed that your program will be loaded into the same place every time it's run. In fact, modern OSes will intentionally randomize the placement of your program on every run. It's a security feature (harder to write exploits when everything is at a random place every time).

Even if your program is loaded at the same address every time, when you compile your code again, all the function addresses will likely be all over the place again.

By the way, function pointers should never be stored across program instances. You aren't guaranteed that your program will be loaded into the same place every time it's run. In fact, modern OSes will intentionally randomize the placement of your program on every run. It's a security feature (harder to write exploits when everything is at a random place every time).

That's why I decided to dump my storage idea and started assigning them dynamically.
Hard coding can never a good idea....It smells fishy..!

or..do you mean, even the other approach shouldn't work ?

..say.. I have a void (*foo)(int);
and void bar(int);

What I'm doing now is plainly foo = &bar; using a similar approach as suggested by 'Salem' and it seems to be working.
Are you categorizing it as undefined behaviour(i.e...setting them at compile time) ?

saving that address to hard drive, then loading it back up when the program starts again and try to execute that function call

I just love segfaults ... ..or executing a tail instead of a head.