That seems pretty legit - thanks Jeremy.
Of course, now I just feel guilty that I'm wasting an extra 1k of
volatile memory in my module... :)
- Chip
--- In Crestron@..., Jeremy Weatherford <xidus.net@...> wrote:
The result of mid() seems to get stored in a temporary variable even
if you just assign it to a local variable. Here's an example from
Crestron's BKParser.usp, line 245:
Temp1$ = Mid(Temp$[4], 2, (Temp[4] -2)); //Get Name string
And here's what it compiles to:
UpdateSourceCodeLine( INSTANCE_PTR( S2_BKParser ), 245 );
FormatString ( INSTANCE_PTR( S2_BKParser ) ,
LOCAL_STRING_STRUCT( __FN_DST_STR__1 ) ,2 , "%s" , Mid (
LOCAL_STRING_STRUCT( __FN_DST_STR__ ) , GetStringArrayElement (
INSTANCE_PTR( S2_BKParser ), LOCAL_STRING_ARRAY( __TEMP$ ) , 4
) , 2, (GET_LOCAL_INTARRAY_VALUE( S2_BKParser, __TEMP, 0, 4 ) - 2))
) ;
FormatString ( INSTANCE_PTR( S2_BKParser ) ,
LOCAL_STRING_STRUCT( __TEMP1$ ) ,2 , "%s" , __FN_DST_STR__1 ) ;
In this case, there's a temporary variable named __FN_DST_STR__1 used
for the result of Mid(). I seem to remember seeing string overflow
error messages for variables with names like that. I'm guessing
they're generated for any kind of string expression, although it seems
odd to use it for a simple assignment. Generated code is never the
paragon of efficiency, though...
Jeremy
On Fri, Jan 23, 2009 at 11:53 AM, Chip Moody <cfm@...> wrote:
This is actually something I was wondering about when I made the XM
Now Playing module, and just couldn't bring myself to write TBTS
on this.
In the XM module, I take the result of a MID function and pass it to
one of my own functions that in turn manipulates the results of the
MID and returns the result of THAT manipulation.
If I could abbreviate/abstract it, it might look something like this:
STRING_FUNCTION Fudge (STRING src$)
{
// Among other things, do something along these lines:
Garbage$ = REMOVE(";",src$);
// Blah blah, more code here...
RETURN (MyProcessedString$);
}
PUSH Go
{
tx$ = Fudge (MID(SomeExistingStringVar$,3,6));
}
My mindset was that the result of MID doesn't exist as a variable,
so I can't really mess around with the contents of that result like I
show in that snippet up there. So in the ACTUAL module, one of the
first things that happens inside Fudge is I copy "src$" into local
variable "temp$", then work on temp$ exclusively:
STRING_FUNCTION Fudge (STRING src$)
{
temp$ = src$;
// Among other things, do something along these lines:
Garbage$ = REMOVE(";",temp$);
// Blah blah, more code here...
RETURN (MyProcessedString$);
}
Does that make sense? Does anyone know for certain if what I did
was required, or does the result of MID (or any other string function
for that matter) exist in some malleable state that I can operate on?
Thanks,
- Chip
--- In Crestron@..., "Oliver Hall" <oliver.hall@> wrote:
This is where foo pipes up to say that Crestron's implementation of
ByRef does actually make a copy the data 8)
------------------------------------
Check out the Files area for useful modules, documents, and drivers.
A contact list of Crestron dealers and programmers can be found in
the Database area.
Yahoo!
Groups Links
--
Jeremy Weatherford
