realbasic-nug
[Top] [All Lists]

RE: Merits of nested DIM (WAS re: [ANN] RB Code Reports version 1.3)

To: REALbasic NUG <realbasic-nug at lists dot realsoftware dot com>
Subject: RE: Merits of nested DIM (WAS re: [ANN] RB Code Reports version 1.3)
From: Andy Dent <dent at oofile dot com dot au>
Date: Tue, 01 May 2007 12:49:31 +0800
Delivered-to: listarchive at realsoftware dot com
Delivered-to: realbasic-nug at lists dot realsoftware dot com
References: <NAEEKPONICFANBGONHNIAEBOEBAA dot tim at telios dot com>
Quoting Tim Hare <tim at telios dot com>:


> Note, however, that there is overhead associated with DIM in that it
> initializes the variable; it isn't purely a scope thing.

1) I put DIM in blocks to guarantee scope so I know something is  
released at the end of the block, for objects. This is more often for  
if/then blocks than loops. It is a more robust coding practice as it  
avoids accidental use of the variable beyond a point at which it might  
be valid (the compiler is your friend).

2) I frequently have native types with a local DIM, sometimes for  
intermediate values. This is a habit from C++ programming but it  
provides a lot more clues to a compiler that it can optimise that  
variable into a register rather than having to do a wider analysis to  
determine if a variable allocated earlier is used outside the block.  
Whilst RB may not do that kind of optimisation now, it could move to  
it in future and my code will automatically benefit. I admit to not  
having looked at the generated assembly but I suspect there's little  
overhead for having a native type with local DIM in a loop as opposed  
to a DIM outside the loop and assignment of a new value within.
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>


<Prev in Thread] Current Thread [Next in Thread>