Re: Window API Coding
- Posted by Derek Parnell <ddparnell at bigpond.com> Nov 12, 2002
- 417 views
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