Feasible strategy for interpreting instructions?
Hi, I'm interested in knowing if this approach of solving a problem is an appropriate one. I would like to specify a thing's behavior intuitively in terms of states without a lot of hassle for each new behavior.
To solve this, I've been thinking about reading in a text file into memory; this contains all the behavior data; for example:
Obviously, 'walk 1 step forward', 'turn left', starting from the 'Initial' state and asynchronously jumping to the 'Collision_Wall' state when this thing bumps into a wall will have to be implemented by the program itself. But I was thinking that, if I can't take the compiled binary and add any more functions to it externally (or can I?) I could write very simple functions in the program, and have the program read a file that tells it what to do with those simple functions. Is this a feasible idea?
If this is a good idea, there's also another thing I would like to ask. When I read in this file, I have to provide some mechanism to translate from my behavior information to actual results in the program. I could do something like using a lot of if/else or switch/case statements to determine what a line is saying, and then call the appropriate functions after parsing that string's information. Something that I'm worried about: is it necessarily bad to have a lot of if/else or switch statements to determine what something is and to do an appropriate behavior according to that?
Also, when I read in the string, I'm worried about the runtime efficiency of parsing all those strings every time I need to interpret it. Perhaps I could encode the function; for example, 'turn' would be 00 and 'left' would be 1, so 'turn left' would be 001. This way, I don't need to store strings in memory and keep rereading them; I can just store them as integers or arrays of chars, which seem like they'd be faster to process. Is this a good idea?
To solve this, I've been thinking about reading in a text file into memory; this contains all the behavior data; for example:
|
|
Obviously, 'walk 1 step forward', 'turn left', starting from the 'Initial' state and asynchronously jumping to the 'Collision_Wall' state when this thing bumps into a wall will have to be implemented by the program itself. But I was thinking that, if I can't take the compiled binary and add any more functions to it externally (or can I?) I could write very simple functions in the program, and have the program read a file that tells it what to do with those simple functions. Is this a feasible idea?
If this is a good idea, there's also another thing I would like to ask. When I read in this file, I have to provide some mechanism to translate from my behavior information to actual results in the program. I could do something like using a lot of if/else or switch/case statements to determine what a line is saying, and then call the appropriate functions after parsing that string's information. Something that I'm worried about: is it necessarily bad to have a lot of if/else or switch statements to determine what something is and to do an appropriate behavior according to that?
Also, when I read in the string, I'm worried about the runtime efficiency of parsing all those strings every time I need to interpret it. Perhaps I could encode the function; for example, 'turn' would be 00 and 'left' would be 1, so 'turn left' would be 001. This way, I don't need to store strings in memory and keep rereading them; I can just store them as integers or arrays of chars, which seem like they'd be faster to process. Is this a good idea?
Last edited on
Alan Turing;s " 5 - State Turing Machine" .
Any problem which will not run on his machine - using only 5 states , such as read, write, move, stop, increment, will not run on any computer.
So your approach assumption is correct.
You CAN add more functions to it externally; Windows magically does this to some degree - but they have a lot of people to help make this so.
To x-late the behavior information into actual results can be accomplished via "Rules" and "Classes" usually found in DLL's or sometimes structures of classes.
If you use a lot of IF/ELSE's then your app will quickly become a tangle of spaghetti code; slow to run, impossible to debug, and miserable in general.
The CPU ( or GPU ) time required to process the strings will not be more, generally speaking, of say, XML, which is really slow ( to the machine's thinking), because XML is mostly in English ,but still fast to us humans.
turn could be 00 and left 1 and left turn would be 001.
and parsing through a line of 10100100100101010101001000100101001
to debug why it goes in circles will take you longer than, well, just too long.
But you 'could' use #directives like #TRUE=1; , #FALSE=0; , #RTurn = 123, #LTurn = 321, #rollover = 0xffff.
My suggestion is to first lay out your design in pseudo code ( can be googled) - Keeping attention to your naming conventions :
int i_answer,
struct a_tempArray,
float f_dbl_rtn_from_there,
char s_MyNameIs.
And naming your vars with sensible names other than :
a,c,b, i,j, m,n, and x,y,z,
or a1, b2, c3, or ans, temp, hold, rtn, val and the like.
The basis of your concept is very good. It will require a lot of thought to hammer-out the direction of I/O that you will want to incorporate, but c++ will be a good language for this task. Too, you may want to consider using a strong back-end for this as well, such as ADO , SQL, Oracle to handle the storage & retrieval end.
".Net and XML" and " ADO.NET" both at
dub dub dub oreilly dot com
are both great resources to have at-hand.
Any problem which will not run on his machine - using only 5 states , such as read, write, move, stop, increment, will not run on any computer.
So your approach assumption is correct.
You CAN add more functions to it externally; Windows magically does this to some degree - but they have a lot of people to help make this so.
To x-late the behavior information into actual results can be accomplished via "Rules" and "Classes" usually found in DLL's or sometimes structures of classes.
If you use a lot of IF/ELSE's then your app will quickly become a tangle of spaghetti code; slow to run, impossible to debug, and miserable in general.
The CPU ( or GPU ) time required to process the strings will not be more, generally speaking, of say, XML, which is really slow ( to the machine's thinking), because XML is mostly in English ,but still fast to us humans.
turn could be 00 and left 1 and left turn would be 001.
and parsing through a line of 10100100100101010101001000100101001
to debug why it goes in circles will take you longer than, well, just too long.
But you 'could' use #directives like #TRUE=1; , #FALSE=0; , #RTurn = 123, #LTurn = 321, #rollover = 0xffff.
My suggestion is to first lay out your design in pseudo code ( can be googled) - Keeping attention to your naming conventions :
int i_answer,
struct a_tempArray,
float f_dbl_rtn_from_there,
char s_MyNameIs.
And naming your vars with sensible names other than :
a,c,b, i,j, m,n, and x,y,z,
or a1, b2, c3, or ans, temp, hold, rtn, val and the like.
The basis of your concept is very good. It will require a lot of thought to hammer-out the direction of I/O that you will want to incorporate, but c++ will be a good language for this task. Too, you may want to consider using a strong back-end for this as well, such as ADO , SQL, Oracle to handle the storage & retrieval end.
".Net and XML" and " ADO.NET" both at
dub dub dub oreilly dot com
are both great resources to have at-hand.
Last edited on
| I can't take the compiled binary and add any more functions to it externally (or can I?) |
1. Checks if a dynamic library is present.
2. If it is, attempts to load it and its functions.
3. If successful, calls a function in the library that returns an array of function pointers.
Step #3 lets you add as much behavior to the program as you want without having to recompile the program. Additionally, because the libraries are dynamically loaded, you can define in a configuration file library names for the program to search. This way you can even add as many libraries as you want (within reason) without recompiling unrelated libraries.
PROS:
* Good performance because you're running native code directly, without any extra cost.
CONS:
* Writing C/++ takes more time than other languages.
* Writing dynamic interfaces between C++ modules is tricky. Due to name mangling, you can't export C++ symbols in the dynamic library if you expect the library and the program to not necessarily be compiled by the same compiler and compiler version. You have to export C symbols. This leads to other restrictions.
* (I think) it's possible to implement dynamic reloading (that is, pausing execution, unloading the library, then reloading a new version of the library and resume execution as if nothing had happened), but it's complicated. Also known as "hot swapping".
This is one way of implementing a plug-in system.
Another is to use an interpreted language to define behavior at run time. The idea is pretty much the same, only instead of loading executable code, you load scripts that the program reads as it goes. If you want to use this, you can either create your own language, or use an existing language. If you choose the latter option, I suggest Lua. It's specifically designed to be embedded in C/++, and it has coroutines, which make defining state machines easy without going outside of the procedural paradigm.
PROS:
* Scripting languages are typically easy to write in.
* There's no need to deal with binary compatibility issues because no binaries exist.
* Dynamic reloading is often explicitly supported by the language.
CONS:
* Performance is always worse than with native code. In some cases, much worse (*cough*Python*cough*).
Hmm, I see. It's good to know that I'm at least on the right track with this. I'm thinking of maybe using SQLite to store and retrieve the script code at some point, although simple .txt files should be enough for now, I think. Dynamic libraries sound interesting, but they seem to be rather excessive for my purposes. Hopefully, the overhead from reading in the file(s) and translating them into data only once won't be a major slowdown on the program. Thanks for the advice, guys!
Topic archived. No new replies allowed.