STATIC elements in UDT

[ErosOlmi]

Next thinBasic preview will have STATIC UDT Elements.
_________________________________________________
Static elements are elements in common to all UDT variables derived from the same UDT TYPE.
They are not part of the UDT structure itself but are available to all UDT of the same type.
Static variables retain their values as long as the program is running.

See following example:



uses "console"

type tUDT
'---Static elements will retains their values for the run of the application
'---Static elements are in common to all variables of type TUDT
static sLong as long
static sLong2 as long
static sStr as string
static MyStaticArray(10) as long
static MyStaticStringArray(100) as string

lLong as long

end type

dim MyUDT_1 as tUDT
dim MyUDT_2 as tUDT

MyUDT_1.lLong = 123
MyUdt_1.sLong = 999

MyUdt_1.sStr = "Whatever string can be applied to a string static element"

printl "Size of MyUDT is: " & sizeof(MyUDT_1.lLong)
printl string$(70, "-")
printl " MyUDT_1.lLong:", MyUDT_1.lLong
printl " MyUDT_1.sLong:", MyUDT_1.sLong
printl " MyUDT_2.sLong:", MyUDT_2.sLong
printl " MyUDT_2.sStr :", MyUDT_1.sStr
printl string$(70, "-")

MyUdt_1.sLong = MyUdt_1.sLong + 999
printl " MyUDT_2.sLong:", MyUDT_2.sLong
printl string$(70, "-")

MyUdt_1.MyStaticArray(10) = 10
printl " MyUdt_1.MyStaticArray(10):", MyUdt_1.MyStaticArray(10)
printl string$(70, "-")

MyUdt_1.MyStaticStringArray(98) = "Again whatever string alloved in a static string element."
MyUdt_2.MyStaticStringArray(99) = "Static elements are in common to all UDT of the same type"
MyUdt_2.MyStaticStringArray(100) = "so changing in one variable will also effect all the others."
printl " MyUdt_2.MyStaticStringArray( 98):", MyUdt_2.MyStaticStringArray(98)
printl " MyUdt_1.MyStaticStringArray( 99):", MyUdt_1.MyStaticStringArray(99)
printl " MyUdt_1.MyStaticStringArray(100):", MyUdt_1.MyStaticStringArray(100)
printl string$(70, "-")

printl
waitkey

[Charles Pegge]

Hi Eros,

You are getting dangerously close to OOP - when some of the static members become function pointers.. ;)

Charles

[Petr Schreiber]

Very interesting Eros,

so kind of shared properties? Are those values linked using pointers and "decoded" at the time when accessing them? Will those members look as DWORD pointer values when passing them to external functions? Is there life in Space?

[ErosOlmi]

Very interesting Eros,

so kind of shared properties? Are those values linked using pointers and "decoded" at the time when accessing them? Will those members look as DWORD pointer values when passing them to external functions? Is there life in Space?


I'm sure there is life in space (we live in space ;) ). I'm not sure about other questions :D

[ErosOlmi]

Hi Eros,

You are getting dangerously close to OOP - when some of the static members become function pointers.. ;)

Charles


I'm making a preparatory work.
STATIC is the first step.
Simple METHODs will be the second.

In my mind I want UDTs compatible with CLASSEs and used interchangeably when possible.
Anyhow there will be a lot of work (I suppose months) before having something usable.

Adding basic STATIC handling was quite easy but not yet finished. I'm now working to inject this possibility in all places where an UDT element is allowed.

We will see.

Eros

[Charles Pegge]

Hi Eros,

Thinking about O2 compatibility:

Will the UDTs contain a pointer to the static members or are the static members mapped externally by thincore?

Charles

[ErosOlmi]

Every UDT, among other things, has a pointer to a hash table containing name/data pairs of STATIC elements.
Data is than another structure, the same used for standard variables.
For each of them I can produce data PTR or structure info PTR but of course those are not compatible with O2.

I do not know if I can be O2 compatible but I will think about it before going too much deeper.
For Classes, you mainly have as first element a PTR to a virtual table containing pointers to static members and methods? Is this right?
I need to study O2 sources and see what I can do.

Eros

[Charles Pegge]

Yes Eros it is like a C++ or COM object. The first element is a pointer to a virtual table which may include both class static elements and function pointers.

The reason for including this pointer in the body of the object is to allow external systems to invoke the object. If the objects are for internal use only, the compiler/interpreter knows where the function table is and would have no problem in pushing its pointer directly onto the stack whenever an object method is called.

But having this pointer in the UDT would enable thinBasic to invoke O2 objects directly and vice-versa.

Charles

[kryton9]

I love reading about what is going on here... it is making my day! The first steps to oop in thinbasic, woo hoo and clean ties to o2.

[ErosOlmi]

wait wait wait :lol:

We are just at the beginning testing and thinking about possible directions.
A lot of water have to pass under the bridge before having something usable.

But we will try!

[kryton9]

I understand it will take time Eros, but the water under the bridge at least is flowing in the right direction :)

[Charles Pegge]

Setting up OOP structures and function calls is very easy. Managing OOP syntax is the more complicated part. But with sophisticated support for UDTs in thinBasic, most of the work is already done!

Bearing in mind that everything has to be woven into the interpreter, I would implement OOP (with minimal ASM) something like this:




type object_class
pvft as long
' other elements
a as long
b as long
end type

'CREATE VIRTUAL FUNCTIONS

function fun1(this as object_class, [other params]) as [return type]
this.a=
...
end function

function fun2(this as object_class, [other params]) as [return type]
...
end function


'CREATE VIRTUAL FUNCTION TABLE

dim virt_fun_table(n) as long

virt_fun_table(0) =codeptr(fun1)
virt_fun_table(1) =codeptr(fun2)

'CREATE VIRTUAL TABLE POINTER

dim pvft as long
cpvft=vartptr(virt_fun_table(0))


'CREATING OBJECTS

dim ob as object_class

' each object initialised with its class vft pointer

ob.pvft=cpvft

CALLING THE CLASS FUNCTION GENERICALLY:

'1: get the function pointer from the table

dim absolute vft(n) as long at ob.pvft
fun=vft(1)

'2: push the params onto the stack in reverse order
'if you are passing params BYREF then push the param address onto the stack instead.

a=varptr(param2)
! push a
a=varptr(param1)
! push a

'3: then push self last of all

a=varptr(ob)
! push a

'4: then make the call

! call fun