Hi.
Is there a way to determine (at run time) the type of variable that is being used, i.e. whether the variable, array, etc. is an integer, floating, string, etc.?
Matt
Determining Variable Type
- hellomike
- Posts: 194
- Joined: Sat 09 Jun 2018, 09:47
- Location: Amsterdam
Re: Determining Variable Type
Hi,
Maybe with a combination using the ^ operator and the "Variable storage in memory" help section....
Did you try/test that?
Mike
Maybe with a combination using the ^ operator and the "Variable storage in memory" help section....
Did you try/test that?
Mike
-
- Posts: 114
- Joined: Mon 16 Apr 2018, 06:17
Re: Determining Variable Type
Thanks.
I've tried a variety of ways, but all of them need to know the variable before its type is determined.
The reason I wanted to know was in order to create a subroutine that dimensioned an array from DATA elements, but that the routine determined the type of array that needed dimensioning. That is, you could pass any type of array to the single routine (directly or indirectly) and the routine would do the rest. I've got a basic one working, but it has four DEF headers, each knowing ahead of time which type the array is. (Not sure how well I explained that.)
The code requires data to be placed after the appropriate label such as (data_list) and finishes with the final element of "END_DATA_SET".
The array is only one dimensional, but it still works. I'll expand it further if I need it. However, I don't like the four DEFs, and there are so many CASEs that it looks like a lost luggage department.
Matt
I've tried a variety of ways, but all of them need to know the variable before its type is determined.
The reason I wanted to know was in order to create a subroutine that dimensioned an array from DATA elements, but that the routine determined the type of array that needed dimensioning. That is, you could pass any type of array to the single routine (directly or indirectly) and the routine would do the rest. I've got a basic one working, but it has four DEF headers, each knowing ahead of time which type the array is. (Not sure how well I explained that.)
Code: Select all
REM Returns a dimensioned array and filled with the data listed DATA.
REM *** NOTE *** The original array passed by reference must be a GLOBAL array
REM and not one assigned by LOCAL.
REM It is important to use the correct PROC's name.
REM *** NOTE *** Requires the last DATA element to be "END_DATA_SET".
REM This element will NOT be saved to the array.
DEF PROCDataFillBytArray(RETURN array&(), datapoint%) : LOCAL T% : T% = 0
DEF PROCDataFillIntArray(RETURN array%(), datapoint%) : LOCAL T% : T% = 1
DEF PROCDataFillNumArray(RETURN array(), datapoint%) : LOCAL T% : T% = 2
DEF PROCDataFillStrArray(RETURN array$(), datapoint%) : LOCAL T% : T% = 3
LOCAL I%, C%, W&, W%, W, W$
RESTORE datapoint%
REPEAT
READ W$
C% += 1
UNTIL W$ = "END_DATA_SET"
C% -= 2
IF C% = -1 THEN ENDPROC
CASE T% OF
WHEN 0: DIM array&(C%)
WHEN 1: DIM array%(C%)
WHEN 2: DIM array(C%)
WHEN 3: DIM array$(C%)
ENDCASE
RESTORE datapoint%
FOR I% = 0 TO C%
READ W$
CASE T% OF
WHEN 0: array&(I%) = VAL(W$)
WHEN 1: array%(I%) = VAL(W$)
WHEN 2: array(I%) = VAL(W$)
WHEN 3: array$(I%) = W$
ENDCASE
NEXT
ENDPROC
The array is only one dimensional, but it still works. I'll expand it further if I need it. However, I don't like the four DEFs, and there are so many CASEs that it looks like a lost luggage department.

Matt
- hellomike
- Posts: 194
- Joined: Sat 09 Jun 2018, 09:47
- Location: Amsterdam
Re: Determining Variable Type
Yes, I see. Looks tricky.
Seems you can get rid of all local variables starting with W, except W$, not?
Anyhow, can't think of a more straightforward way of achieving what you need.
Would be nice if Richard would still be on-board to give advise.
Mike
Seems you can get rid of all local variables starting with W, except W$, not?
Anyhow, can't think of a more straightforward way of achieving what you need.
Would be nice if Richard would still be on-board to give advise.
Mike
-
- Posts: 114
- Joined: Mon 16 Apr 2018, 06:17
Re: Determining Variable Type
I've been using the Cross Reference utility and that obviously has a way of determining what type of variable is being used. So I guess there must be a way - unless it determines it directly from the listing.
I agree with you final comment about Richard.
Matt
I agree with you final comment about Richard.
Matt
- hellomike
- Posts: 194
- Joined: Sat 09 Jun 2018, 09:47
- Location: Amsterdam
Re: Determining Variable Type
Cross Reference only looks at the tokenized source. Program isn't running at that moment.
Pretty sure it interprets the source about the same as interpreter does during run time. So it simply uses the actual last character of the variable name. %, $, &, <none>. Their purpose is not just readability I'm sure.
Have you checked the help for the CALL statement. That does a lot with parameter types!
Also related is:
Calling internal routines from assembler code
Hope this helps.
Pretty sure it interprets the source about the same as interpreter does during run time. So it simply uses the actual last character of the variable name. %, $, &, <none>. Their purpose is not just readability I'm sure.
Have you checked the help for the CALL statement. That does a lot with parameter types!
Also related is:
Calling internal routines from assembler code
Hope this helps.
- hellomike
- Posts: 194
- Joined: Sat 09 Jun 2018, 09:47
- Location: Amsterdam
Re: Determining Variable Type
this wiki page states:
CALL @fn%(4) ; Look up variable (esi points to name, returns type=al, varptr=ebp)
........
CALL @fn%(4) ; Look up variable (esi points to name, returns type=al, varptr=ebp)
........
-
- Posts: 114
- Joined: Mon 16 Apr 2018, 06:17
Re: Determining Variable Type
Thanks. I'll have to look into the CALL statement.
I don't have v6 so I can't use the @fn%() function.
Thanks for looking.
Matt
I don't have v6 so I can't use the @fn%() function.
Thanks for looking.
Matt