|
It depends on how the input is handled initially. If the input is simply left in the streambuffer until the program is ready to accept another command from the user, then the first step is to make sure that that buffer is cleaned as soon as new input is sent.
This information should then be placed in a queue, statement by statement (the command statement ending with a \n\r). This queue would then be manipulatable enough to perform functions such as "clear" on. (A clear would probably consist of simply going through and freeing the memory currently in the buffer, and nulling out the pointers to those char strings).
It's important to have it in this form before you implement the clear however, since in order for the "clear" command to work, it can't be implemented as an actual command. Instead, as the data arrives, the new "statement" would have to be checked. If it says clear, immediately clear your buffer. If not, then add the contents to the buffer. When the client is ready to accept a new command, simply pop the next command off the queue.
More simply, you're just adding another level to your command interpretation.
Where-as before you had (probably):
Input from TCP protocol --> Application streambuffer --> command recognition --> command execution/error message
You now have:
Input from TCP protocol --> Application streambuffer (dumped upon arrival of full statement) --> pre-processing to check for "clear" --> entry command queue (or clear of queue) --> command recognition --> command execution/error message
We perform a similar process on user input, only we implement more layers between the buffer and command execution then even this model. Thus we've separated commands into "realtime" commands and "gametime" commands: those commands that need to be executed immediately (such as command-queue processing commands), and those that need to wait until character is ready to execute a new command (following the completion of the last action usually).
|