OpenEuphoria

Re: Linked win32lib structures

• Posted by Derek Parnell <ddparnell at bigpond.com> Jan 07, 2003
• 488 views

----- Original Message -----
From: <who at bellsouth.net>
To: "EUforum" <EUforum at topica.com>
Subject: Re: Linked win32lib structures


>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> To All,
>
> Ive yet to understand why all the overhead Win32lib has and I feel partly
> responsible. When I sent Rob the the information that the .dll files
werent
> being released we assumed there was a memory leak in Euohoria or Win32lib.
> I maybae dont understand why ...

The current routines involved with structures (RAM data mapping) are
designed to reduce errors in the library rather than cause the library to be
as fast as it possibly can be. Its just a matter of prioritites and
trade-offs.

> but why cant we just use get away with
>
> the only draw back to this is sizeofStruct is not a given until all struct
defines
> have their size.
> struct_address = allocate(sizeofStruct)
> mem_set(struct_address,0,sizeofStruct)
>
> contant
>   dwplace1 = 0,
>   dwplace2 = 4,
>   dwplace3 = 8
>
> now we know that sizeofStruct is 12

Another drawback is the issue of reentrancy. If all the memory-mapped data
is allocated fixed locations for the duration of a program, we will have
problems when the same data area is used before the previous use is
completed. This can occur when a routine is invoked from itself, either
directly or indirectly, for example a WM_PAINT handler.

> I dont see the need for the extra overhead is someone would convert the
"store"'d
> values. This too would eliminate the need for "fetch" which is anoverhead
itself.

The "overhead" is always required. Its just a matter of when it is to be
done. Currently win32lib does the offset calculations and selection of the
correct variety of peek/poke at run time. To make the library a little
faster, this overhead could be done by the authors of the library at coding
time. The current method is less error prone than the proposed alternative.

> You'll probably come back with something like all data types arent the
same. yeah
> like T_CHAR for example. I already know this much.

Then you also know that the coder must select the correct offset, which is
dependant on all the data types prior to the field requested, and the
correct form of peek/poke, which is dependant on the size of the field
requested. Win32lib attempts to automate much of this process so as to
reduce mistakes by doing this work by hand.

> Not bitchin just asking,

just answering

--

Derek Parnell