Each parameter is identified by its unique name. It is necessary to define the parameter's data type and its value. Also a caption can be specified as a flag specifying whether the parameter can be changed during the run of the whole system or not. The type specification must be defined before the value definition appears!. The definitions are specified by the parameter name, underline sign, keyword and equal sign followed by the definition.
Example:The type specifiers are:
| Type | description | possible values | example |
|---|---|---|---|
| String | classical array of characters | any, except the "\0" | What a magic |
| Integer | one integer number | any integer, signed or not | 42 |
| Float | one real number | any real number, signed or not | 3.14 |
| Bool | boolean value | TRUE, FALSE | FALSE |
| Prob | a fixed point number
(considered as probability) |
a number with 7 decimals precision
(may fail with numbers out of range <-200%,+200%>) |
53.16% |
| Fit | fitness value | a real number from range <0,1> | 0.9999 |
| Char | single character | any character | A |
The definition of change can be Yes or No. If the definition does not exists Yes is taken as a default value.
If the programmer tries to access inside the code a parameter as a different type then specified in parameter file, internal conversion is made. The conversion routines are described in the chapter of utils.h in the Reference Book. But note that during the conversion, the value can be very distorted.
The groups should simplify the orientation in the text file. They are also used by the Parameter editor to place the parameters onto different sheets. Sometimes they can also fasten the access to the parameter inside the program. The definition is quite simple: the group name enclosed in brackets and all the following parameters belong to the group.
Example:At the beginning of the file directives can be specified. In this version only one directive is supported. It is a directive #include. It causes the specified file to be loaded into the ParamFile structure.
The parameters of the directive are:Comments are just an explanation for the reader. Every line of comment begins with a semicolon (;).
Example:Every comment before a first parameter definition is considered as a file comment. All others are a part of the last defined parameter (comments can be in the middle of the definition).
[First group]
DemoParameter_Type=String
DemoParameter_Value=Hello world
DemoParameter_Caption=Just a demo
DemoParameter_Change=Yes
[Second group]
P1_Type=Fit
P1_Value=0.65
;You see no caption
P2_Type=Prob
P2_Caption=Success chance
P2_Value=95.5%
This class is a cover of the whole structure and the interface to all the parameters. This class encapsulates the whole idea to pass a single object as a function parameter. This allows to construct other classes without an precise knowledge of the different parameters they require.
The TGroup class has a minor importance. It is a representative of groups in parameter file. It is used for better orientation during visualization of the ParamFile for example in the xparam application. Sometimes it is used for a faster access of parameters, but very rarely, because of the possible misleading results (the parameter can be placed in some other group).
This class stores the parameters themselves, their name, value, caption etc. Also encapsulates the conversion routines. Of course, together with TParamFile, this class is the most important one in the whole ParamFile idea.
This class is in fact the file identification. Because the ParamFile structure, represented by TParamFile, can consist of more than one physical files, it is important to distinct, which parameter belongs to which file. This is the task of TPFileID class, as each TAParam points to the identification of the file it belongs to.
The whole structure than looks some like this :
Where the arrows are pointers.