1707.2 |
Fix |
Compiler edit 955: use of an automapped %m variable in the global context was resulting in a memory error at runtime. |
1707.2 |
Fix |
Compiler edit 954: close two loopholes related to the use of %x auto-mapped variables (see 1707.0 below) which were resulting in spurious compiler error messages. |
1707.1.1 |
Fix |
Compiler edit 953: MX_DYNSTRUCT DYNOP_DEF was not supporting .SIZEOF(var), resulting in a spurious error. Also, it now terminates the define operation as soon as the target DEFSTRUCT is compiled, both speeding it up (when passing files containing many DEFSTRUCTs), and eliminating errors that wouldn't have affected the target structure. |
1707.1.1 |
Fix |
MX_DYNSTRUCT DYNOP_DEF operation now returns both the error message and the source line in the errmsg$ parameter. |
1707.0.1 |
Fix |
Compiler bug fix/refinement (edit 951) to auto-mapped %i variables (see 1706.0). Auto-mapped variables are now confined to local contexts (i.e within functions and procedures) only. And an auto-mapped loop variable must not have been previously defined within the same function as a non-loop auto-mapped variable. |
1707.0.2 |
Compiler edit 952 for MX_DYNSTRUCT support: the default amount of work area memory allocated when defining (compiling) a dynamic structure has been increased from 128K to 2M. While 128K was more than enough for the largest ordinary structure definitions, it wasn't always enough for structures embedded within much large source files, especially files that ++included other files. Defining a dynamic structure requires essentially compiling all of the source code preceding the target DEFSTRUCT to make sure that any dependent definitions or conditionals are properly taken into account. |
|
1707.0.3 |
New |
MX_DYNSTRUCT , DYNOP_DEF Enhancement allows the caller to specify more than the default amount of memory when defining a dynamic structure.. |
