[Laszlo-dev] Compiler Preprocessing [Was: debugger history]

P T Withington ptw at pobox.com
Thu Nov 17 15:58:09 PST 2005


[cc-ing laszlo-dev, which is probably more appropriate for this  
technical level]

On 17 Nov 2005, at 17:48, Scott Evans wrote:

> On Thu, 17 Nov 2005, P T Withington wrote:
>
>> The best practice here is to enclose any debug-only computations in
>>
>> if ($debug) {
>>  ...
>> }
>>
>> The compiler will omit those statements when you compile without  
>> debugging.
>
> Would be a nice compiler pre-processing step, eh?

The compiler _does_ do simple partial evaluation of constants in if  
statements.  This was seen as just as good as #ifdef, without having  
to invent a new syntax or have a pre-processor.

The compiler automatically defines the constant `$debug` to be true  
if you compile your application with --debug, or load it from the  
server with ?debug=true and false otherwise.  Similarly, it will  
define `swfN` as true if you compile with --runtime=swfN or load  
with ?lzr=swfN (for N in the supported range, currently 6-8) and  
false otherwise.

You can define your own compile-time constants to `lzc` by using `- 
D_name_=_value_`, where _value_ should be either `true` or `false`.   
By convention, we use `$` as the first character of _name_, but  
nothing enforces that.

The compiler will compile only the chosen branch of an if statement  
when the condition expression is a compile-time constant (i.e., just  
the constant name, no other computation).  For example:

   if ($slow) {
     ... slow way ...
   } else {
     ... fast way ...
   }

Can be made to run fast by `lzc -D$slow=false`.  If you don't supply  
a value for $slow at compile time, the compiler will emit both  
branches and the if statement will be evaluated at run time.  There  
is currently no provision for passing compile-time constants through  
the server.

Clearly, this mechanism could be abused, making for very unreadable  
code, just as is the case with #ifdef.  Compile-time constants should  
be used judiciously.




More information about the Laszlo-dev mailing list