As said before, the library has been written in ANSI C and is so likely de be built by any C compiler. Attached to the library you can find a makefile, it has been writen for the C compiler gcc under a gnu-linux system.
The library accept at the time of writing 5 diferent options to adjust the way it work.
To see real effects of the different optimisations, see numerical information.
This will save a large amount of space and make the library work a bit faster but it will deactivate any debug and verbose mode capabilities.
Might cause the lib to work more slowly during initialization especially if you don't known how to optimize initialisation but it will also optimize runtime complexity passing from O(n²) to O(n*ln(n)) when looking for states transitions in one state (useful only if your states have many transitions). If this option is activated with the debug area 'REALLOC_DBG' you might see some debug like :
[OSM] In State machine myOptimizedStateMachine, for state MS1_1, system have to relocate transitions to insert the newly allocated one.
This mean that some memory segment are copied before the new transition can be inserted. To avoid this see
this section.
- Warning:
- Automatically activate the option OPTIMIZE_RUN.
This option will cause the lib to use extra memory space. The amount of space used is a combination of the maximum depth of the state machine and the number of transition existing in every state stack. At the same time this will cause the lib to work even more slowly during initialization especially if you don't known how to optimize initialisation. If you follow
this section information the extra time that will be used won't be significant.
On the other hand, this option will greatly improve transition lookup specially when you have very deep state stacks. Without this option the lookup complexity is O(n²) or O(n*ln(n)). With this option the linear coefficient will be suppressed and so the complexity will be O(ln(n)).
- Note:
- Depth represent the number of parent states between a state and the root of the state machine.
We call state stack a state with all of its parents. For example consider state MS_1 which have two childs states S1_1 and S1_2. In this case there are two different stack : (S1_1, MS1 ) and (S1_2, MS1).
If set, the state machine will allocate buffer as soon as it start and won't deallocate it until the whole state machine is freed. If not set, the buffer will be allocated before any transition start and will be freed after the transition is over. The amount of memory that will be allocated for the buffer correspond to the maximum depth of your state machine multiplied by the size of a pointer.
- Note:
- depth represent the number of parent states between a state and the root of the state machine. As it is usually a very small amount of space it is highly recommended to set this option as it will avoid dynamique reallocation during runtime.
- Warning:
- make the library become unsafe if used in an unsuitable way (HIGHLY DEPRECATED FOR DEVELOPPEMENT, see this section before using this).
This will increase speed specially during initialization time.
Do the opposit than the previous define. When activated, any argument transmited to any functions will be checked. This will increase time consumption during both initialization and runtime.
The library need to be informed of which architecture you want to build it for. Currently there is only two architecture supported:
Simply add -DARCH_X86 or -DARCH_AMD64 in USER_DEFINES variable to select your architecture. Adding support for another architecture is far from complicated. You can contact the developers to get support for your architecture.
- Note:
- If you don't specify any architecture, the compilation will fail.
If you write any configuration file we will be very thankful to you if you can give it to us to be added in the library sources.
Next:
How to use the library without a heap.
Previous: How to carefully handle the library
