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

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

This is a discussion on How to store a huge list of switch-case like pairs in secondary memory ? within the C++ Programming forums, part of the General Programming Boards category; I'm trying to make a console shell for a simple virtual machine I'm making.
When the shell receives a command, ...

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

Manasij Mukherjee | gcc-4.9.2 @Arch Linux Slow and Steady wins the race... if and only if :1.None of the other participants are fast and steady.
2.The fast and unsteady suddenly falls asleep while running !

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

Manasij Mukherjee | gcc-4.9.2 @Arch Linux Slow and Steady wins the race... if and only if :1.None of the other participants are fast and steady.
2.The fast and unsteady suddenly falls asleep while running !

> 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.
Wow - how many commands are you planning to write to get up to a 10Mb map!

Manasij Mukherjee | gcc-4.9.2 @Arch Linux Slow and Steady wins the race... if and only if :1.None of the other participants are fast and steady.
2.The fast and unsteady suddenly falls asleep while running !

Manasij Mukherjee | gcc-4.9.2 @Arch Linux Slow and Steady wins the race... if and only if :1.None of the other participants are fast and steady.
2.The fast and unsteady suddenly falls asleep while running !

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) ?

Manasij Mukherjee | gcc-4.9.2 @Arch Linux Slow and Steady wins the race... if and only if :1.None of the other participants are fast and steady.
2.The fast and unsteady suddenly falls asleep while running !

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) ?

No, that's perfectly defined. What is undefined is saving that address to hard drive, then loading it back up when the program starts again and try to execute that function call.

Manasij Mukherjee | gcc-4.9.2 @Arch Linux Slow and Steady wins the race... if and only if :1.None of the other participants are fast and steady.
2.The fast and unsteady suddenly falls asleep while running !