>> I assumed (here I go with those nasty assumptions again) that addresses >>were ONLY passed if we expressly instructed an address to pass by way of the >>VARPTR (@) instruction, just as you demonstrated in your example (shown >>above). > >Ouch! You caught me making an assumption too. I assumed that string >variables were always passed via addresses, but I don't know for sure. It >could be that the whole string is copied after all. Its been my experience that the address is NOT passed by default. The variable/string is copied into a local variable/string. For example, in Pascal, you would do one of these two things: Procedure test(myVar:integer); or Procedure test(var myVar:integer); The second example would not copy the integer, but instead, would pass the address to the procedure. This would do two things. First, the value of the integer could be changed by the function. Ssecond, there would be a _slight_ speed increase. The same is true for strings. I am not sure if FB works the same way as pascal, but I would think so. >> In what way does the automatic passing of an address ("...FB passes >>addresses anyways...") allow for less control than is provided when we >>FORCE an >>address to pass (using VARPTR, for example). >> >It just comes back to not trusting the compiler to do what you assume it's >doing. I do a lot of low-level coding, so you get used to working with >addresses in many operations and Toolbox calls. It just seems more natural >to me to pass an address than a string variable. It's simply personal >preference. > >Sorry to let my own personal biases get in the way of providing a clear >answer to your question. The lurkers will no doubt be highly entertained >from watching me scrape the egg off my face. Again, I don't know how FB works internally, but passing the address manually (or using global variables) is probably the only way to avoid making local copies of variables. You always want to use globals/pass addresses for large arrays, etc.