Re: Window API Coding
13/11/2002 11:56:34 AM, euman at bellsouth.net wrote:
>>
>> That is why David Cuny created the allot()/fetch()/store() routines that
>are
>> used in win32lib. These are a trade-off between maintainability and
>> execution speed. I think he did a good job.
>
>SLOW!
Depending on the machine you are using, of course. On the two machines I have
access to, I cannot
notice any significant speed degradation. And this is acknowledging that your
hard-coded peek/poke
method is 5 times faster than the routines used in win32lib. But I can live with
800,000 fetch()
calls per second.
>
>> > Don,
>> >
>> > Ive been writting in C and using Masm32 myself and this Euphoria snippet
>> > is what I use to make code smaller and faster. Just a very small snipp..
>> >
>> > constant
>> > sizeof_trm = 32 -- Size of trm structure
>> >
>> > atom trm
>> > trm = allocate(sizeof_trm)
>> > mem_set(trm,0,32)
>>
>> (shouldn't this be "mem_set(trm,0,sizeof_trm)" 
)
>>
>> > constant
>> > trm_Op = trm + 0, -- Tsunami operation number
>> > trm_File = trm + 4, -- Tsunami file handle
>> > trm_DataPtr = trm + 8, -- Address of data buffer
>> > trm_DataLen = trm + 12, -- Length of data buffer
>> > trm_KeyPtr = trm + 16, -- Address of key buffer
>> > trm_KeyLen = trm + 24, -- Length of key buffer
>> > trm_KeyNo = trm + 28 -- Key number
>> >
>> > ->>>> is definatly better than
>> >
>> > trm_Op = allocate(4)
>> > trm_File = allocate(4)
>> > trm_DataPtr = allocate(4)
>> > trm_DataLen = allocate(4)
>> > trm_KeyPtr = allocate(4)
>> > trm_KeyLen = allocate(4)
>> > trm_KeyNo = allocate(4)
>> >
>> > and then peek4( ) each time you need access to a particular part of the
>> > struct sucks.
>> >
>> > Also, when you peek or poke a value you eliminate the extra "addition"
>(+)
>> > required
>> > e.g, poke4(trm + trm_Op,val) -- why not do this only once at the start
>of
>> > your proggy.
>> >
>> > Maybe this is hard for some to understand but for me this seems easier
>and
>> > besides
>> > is obviously faster with less messy code.
>>
>> You have actually code like this?
>
>Sure do, let me know of a better way in Euphoria Derek.
Sorry for not making myself clear. I was not, and am not, attacking you or your
code. What I was
trying to say was -- have you really seen this style of code ...
trm_Op = allocate(4)
trm_File = allocate(4)
trm_DataPtr = allocate(4)
trm_DataLen = allocate(4)
trm_KeyPtr = allocate(4)
trm_KeyLen = allocate(4)
trm_KeyNo = allocate(4)
. . .
a = peek4u(trm_Op)
b = peek4u(trm_File)
. . .
It is THIS style of code that suggests that the author doesn't understand how to
use RAM
effectively. I was not refering to the method you tend to use; namely...
constant
sizeof_trm = 32 -- Size of trm structure
atom trm
trm = allocate(sizeof_trm)
mem_set(trm,0,32)
constant
trm_Op = trm + 0, -- Tsunami operation number
trm_File = trm + 4, -- Tsunami file handle
trm_DataPtr = trm + 8, -- Address of data buffer
trm_DataLen = trm + 12, -- Length of data buffer
trm_KeyPtr = trm + 16, -- Address of key buffer
trm_KeyLen = trm + 24, -- Length of key buffer
trm_KeyNo = trm + 28 -- Key number
. . .
a = peek4u(trm_Op)
b = peek4u(trm_File)
. . .
However, since you have invited me to suggest improvements...
Your solution is fine so long as you don't need to refer to two or more
different RAM locations
that contain the same structure. The code you have shown has fixed the location
of the trm structure
and the identifiers used to access its components. These identifiers can ONLY be
used to access your
specific single manifestation of the trm structure. They cannot be used to
access other trm
structures, such as ones passed to your code from other routines.
The style of coding you prefer encourages high maintenace costs. If that is fine
for you then you
don't have a problem.
>>If so, the coder would probably benefit
>> from learning a bit more about coding in general.
>
>I have learned all I know from Euphoria and Euphorians itself.
Maybe you you should get out a bit more often 
>Who says code has to be a 1000 lines of complex arithmatic to beat
>my few lines I presented.?
>
No one. Have they?
>>This has nothing to do
>> with API coding. Of course, better support for structured memory areas
>would
>> be nice to have in Euphoria; at least we would have a unified way of doing
>> these necessary chores.
>
>If you want C, then perhaps C suits you better....
>You convert Win32lib over to C and I'll follow.
I do not want C more than a better Euphoria, even though C is a great language
for low-level coding
(device drivers, operating systems, etc...)
I'd love to make win32lib a DLL one day, but first we have to get over the
routine_id passing issue
that presents.
---------
Cheers,
Derek Parnell
|
Not Categorized, Please Help
|
|
