I’ve got a c++ library with a class that implements a virtual machine (called ‘VM’) of a custom programming language. This language have some different instructions that can be executed, among which there is “read value from input” instruction. The VM can be run in two modes: execute single instructions step by step (until machine is done) or execute all instructions at once. It can be also used in two applications: console and a GUI application.
Until now I had only a console application. When the “read value from input” instruction was executed, it just used std::cin to read the value, so the virtual machine stopped until the input was submitted. The problem occurs when I’m trying to create a GUI for the VM. I’ll use a typical text input instead of std::cin.
The question is: what do you think is the best way to model such problem from the point of executing instructions? How should the VM behave when the “read value from input” instruction is executed? Before a user click “execute single instruction” he doesn’t know what kind of instruction is it going to be, so he can’t submit the input before the instruction is executed.
I was thinking about adding a new state property to the VM: {working|awaiting_input}. During the “read” instruction runtime the machine should suspend until it gets the input. And when the GUI layer fetches the input from the user, it’d call VM’s passInput(inputValue) new method which additionally wakes VM up (to either finish the single instruction or all of them). Can you think of an easier solution (e.g. without adding a state property)?
The first step is to break out your “input” from being an integral part of the VM engine [which it sounds like it is now], so that when you get the “read value from input”, you just call a “do_input” function – a virtual function implemented in the “user_interface” class – which could be either UI or iostream.
Whether it’s running in single-stop or “full speed” shouldn’t make any difference, the “instruction” doesn’t complete until the input has been gathered, right?
Now, GUI can be quite tricky, as it tends to be event-driven, and input is just another event. However, if you implement your “do_input” function as a function that only return when input has been read, then it’s not really any big deal. You just need some (part of a) window as “this is where you enter input” and the user will have to type something to that. When the user hits enter (or clicks a button, etc), then you have your completed input.
You may also want to have a mode where input is read from a file… 😉
It probably is a bit more complicated than I’ve just described, but shouldn’t be a huge amount more than that. [I’ve done similar things in instruction simulators before, where one instruction can effectively take an “infinite” amount of time, because it waits for input].