IT-Berater: Theo Gottwald (IT-Consultant) > Brians Board

PluriBASIC - Progress of the implementation for Oxygen

<< < (9/9)

Brian Alvarez:
 Posting this here just so that i dont forget, but it might change a bit:


When obj is a numeric datatype, like LONG, INT, QUAD, SINGLE, etc. It returns the number of bytes for the data type, for example BYTE returns 1, and QUAD returns 8.
When obj is a string datatype like STRING, WSTRING, ASCIIZ, etc. (including JSON), it will always return 0, unless GUID is used, which will always return 16.
When obj is a function, the datatype will be it's return data type, and the same rules as in case 1 and 2 will apply.
When obj is a variable, the datatype will be the variable data-type, and the same rules as in case 1 and 2 will apply, except that in this case, if the variable is of a string datatype, TYPESIZE will return the length of the string definition. For example, for dynamic strings, it will return 0 (to know the length of the data stored in it, use LEN), and for fixed length strings it will return the fixed size, for example, for strings defined like this:

--- Code: ---STRING s AS STRING * 20
--- End code ---

 TYPESIZE will return 20, even is the data stored in it use less characters.
When obj is an user-defined-type, or a variable of an user-defined-type, TYPESIZE will return the size in bytes of the udt structure.

Almost forgot....
TYPESIZE also supports individual UDT members.

Mike Lobanovsky:
I wonder what exactly this operator is going to return in case of respective arrays?

Brian Alvarez:

--- Quote from: Mike Lobanovsky on June 04, 2019, 08:21:07 PM ---I wonder what exactly this operator is going to return in case of respective arrays?

--- End quote ---

 For the elements of an array, it behaves as it would with a variable.

Edit: I hastefully edited my previous post... I am thinking that for arrays TYPESIZE can return
two different vallues, one for compilation-time, and another for run-time. This is not yet implemented,
but it could return 0 if the array was not prevously (command-order wise, not execution wise) DIMmed,
and 1 if the array was previously DIMmed. This would allow TYPESIZE to be used in COMPILE statements.

--- Code: ---DIM arr(10) AS STRING

IF TYPESIZE(arr) COMPILE  ' evaluates as true at compilation time
    ? "Size of array is " + STR$(TYPESIZE(arr))  ' gives exact array size at run time.
   ? "Hey you developer! Dimension this array first!"
--- End code ---

As i said... this is not yet implemented but, it makes sense to me....

Brian Alvarez:
Notes about MACROTEMP and c++ style variable definition.

 MACROTEMP does not (at the moment) support dimensioning variables using the c++ declariation style.

When using MACROTEMP variables in a macro, its easy to detech wich variables are being declared, and then
converting them to temporary variables because the LOCAL, STATIC, GLOBAL, etc. declaration functions make it
easy to detech which ones are being declared. But since TYPEs, STRUCTs, CLASSes and UNIONs are not parsed
until macros are expanded (UDT's can also be generated dynamically), there is still not a clear idea of what
variables are being declared that way. For example, in this code:

--- Code: ---MACROVAR a

--- End code ---

It is easy to declare a as a MACROVAR or whatever type, even if the UDT type is not yet declared. But here:

--- Code: ---SOMEUDT a
--- End code ---

  Is ambiguous... It could be a function or sub being invoked without brackets, using a as a parameter (becuase UDT's or modules are not yet parsed)...

 Im sure i can find a way to make it work, but, for now, and until i find a way that pleases me, MACROVAR variables will require BASIC declaration methods and will not work with c++ mode.


[0] Message Index

[*] Previous page

Go to full version