Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Why define constants
Message
From
27/10/2006 06:37:02
 
 
To
26/10/2006 00:22:01
General information
Forum:
Visual FoxPro
Category:
Coding, syntax & commands
Miscellaneous
Thread ID:
01164235
Message ID:
01164937
Views:
10
Hi Jos,

(and JimN, as this touches a few points I was near posting to you as well <g>)

>David, would you care to hazard a guess at a number at which point using #DEFINE might start making a difference on modern cpu's? iow, at what point might a programmer start worrying about this.

there are a few more facets to consider here. Running an unencumbered vfp (a few dozen of memvars visible) the effect of difference between a variable and the raw value from a constant is minimal and usually not a problem even in large SQL queries or tight loops. When running *non-looped code*, re-using a variable might actually be faster, as the comparable code sequence is shorter (less to load) and a variable lookup might be handled by the cache.

But vfp *can* deteriorate exponentially if you overuse single resources, like opening tables / cursors and never closing - a couple of hundred will be ok on a beefy machine, but don't get to near to thousand or try for 30000... So if I have a common lookup reused for many things table I will access it via oApp instead of opening in each form a cursor for each key to check.

The same with objects: after vfp8 even a few thousand are ok (NOT counting forms and formsets!!), each baseclass taxing the "system" vfp differently.

Arrays and Memvars are similar: if you bend the numbers out of shape, you may suffer <g>. But current programming style (frowning on a couple of hundred globals) protects you well enough.

Still, my resolve is similar to David's rule: Keep a single location in your code. If there is a common theme, create an object. If that is too much effort, stay with #defines and perhaps either a table, a prg feeding an array or flat file for large amounts of text. Be sure to have talking names.

The MsgBox example should IMHO be a simple method with a long descriptive name. When used without parameters (as should be the usual case), sensible defaults for that method should be used but might be overrriden by using parameters. Constants for the msgBox-behaviour should become properties. That is, IF you often use MsgBoxes...

If a value is needed in heavy SQL and currently only costly to access via table/array-lookup or traversing a long object tree, copy the value once to a local before using it in a query or tight loop. Just my try to run a "tight ship" without too many sloppy programming practices - knowing that "sloppy" in this context is largely a matter of personal taste.

regards

thomas
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform