For some reason, LSL only allows postfix expressions after a type cast. This extends the syntax to allow prefix expressions as well. This means that you can write e.g. (string)(integer)a instead of (string)((integer)a), or (string)++x instead of (string)(++x), sparing you from having to enter the extra parentheses.
For some reason, LSL only allows postfix expressions after a type cast. This feature extends the syntax to allow prefix expressions as well. This means that you can write e.g. (string)(integer)a instead of (string)((integer)a), or (string)++x instead of (string)(++x), sparing you from having to enter the extra parentheses.
The optimizer option ProcessPre enables processing of certain preprocessor directives that control compilation. Only #pragma and #line are supported for now. Typically these directives pass through the preprocessor unchanged, so they will reach the optimizer if a preprocessor is used. The rest of preprocessor directives will be ignored.
The optimizer option ProcessPre enables processing of certain preprocessor directives that control compilation. Only #pragma and #line are supported for now. Typically these directives pass through the preprocessor unchanged (not always; see note below about gcc and #line), so they will reach the optimizer if a preprocessor is used. The rest of preprocessor directives will be ignored.
#pragma is a special C preprocessor directive that allows compilers to extend the language with certain options. In the case of this optimizer, the #pragma directive is used to enable/disable on the fly the parsing options and extensions. Even ProcessPre itself can be disabled (it can't be enabled this way because when disabled, #pragma directives aren't processed).
Note: GNU cpp actually generates a preprocessor command that only contains the line number and the file name, pretty much like a #line directive does, but without the line part. The parser deals with that format correctly, treating it as if it was a #line directive.
Note: Firestorm prepends a // comment to the #line directives that Boost::Wave generates; since the optimizer doesn't use Firestorm's output directly, it doesn't interpret these lines.
Note: Firestorm prepends a // comment to the #line directives that Boost::Wave generates; since the optimizer doesn't use Firestorm's output directly, it doesn't interpret these lines specially.
Note: Pragma operators of the form _Pragma("pragma string") introduced in C99 are not supported.
case labels can't appear in nested blocks. That's because they are replaced by LSL labels, and as discussed in the Multiple labels with the same name section above, label scope rules prevent their visibility in an outer block, so once converted to labels, the corresponding jump instructions would not be able to find them. This limitation means that Duff's device or similar constructs can't be implemented with this optimizer.switch() needs to be followed by a block, not by a single statement. For example, whiile this works in C, it won't work in this optimizer:switch() needs to be followed by a block, not by a single statement. For example, while this works in C, it won't work in this optimizer: switch(1) case 1: break;case is treated by this parser as a statement, rather than as a label prefix, making break be outside the switch and thus failing at that point. This limitation is probably only of theoretical importance and will not have any practical implication, since single-statement switch clauses are of little or no practical use (known to the author). Of course it works perfectly when enclosed in braces: switch(1) { case 1: break; }will, under any system which has an editor called notepad, read myscript.lsl, optimize it, and write the optimized result to temp.opt, then open it in the editor, enabling you to copy it and paste it into the viewer. Under Windows version Vista and above, apparently there's a command line application called clip that does the same as xclip does for X Window, enabling you to use this:
will, under any system which has an editor called notepad, read myscript.lsl, optimize it, and write the optimized result to temp.opt, then open it in the editor, enabling you to copy it and paste it into the viewer. Under Windows version Vista and above, there's a command line application called clip that does the same as xclip does for X Window, enabling you to use this:
python main.py myscript.lsl | clip
to copy the optimized output to the clipboard. Under OS X, it seems pbcopy does the same as xclip and clip.
to copy the optimized output to the clipboard. Under OS X, pbcopy does the same as xclip and clip.
An external preprocessor is supported. If your system has a GNU C Compiler suite already installed, then the cpp that comes with it (or gcc adding the -E option) should be enough. If you don't have it, the recommended preprocessor is mcpp, because it's a standalone executable, easy to install. Download it from http://mcpp.sourceforge.net/download.html, unpack the executable somewhere in the system path (or specify the path to the executable every time with the --precmd option of the program) and you're ready to go.