Window API Coding
----- Original Message -----
From: <euman at bellsouth.net>
To: "EUforum" <EUforum at topica.com>
Subject: Re: What we really need...
>
> >Win32Lib does a superb job of hiding
>
> superb???
Agreed, it is not a superb hiding job. It could definitely be improved, and
hopefully will be.
> > the details of what is going on behind the scenes. API programming is
> > not for the faint of heart.
>
> Yeah atleast its your code and you can fix it to work like you want it to.
Your perspective is from a lone coder. Most programming in the world is done
in teams and is maintained by people other than the original coders. We
simply do not have the luxury of disregarding the needs of other
programmers. "Cowboys" need not apply.
> >There are more constants, data types, and
> > structures than you can shake a stick at. I have one file at home
> > *one*, which is about 55k full of nothing but constants. Nothing else.
>
> AGREED.
>
> > Point? It is easier for me to code API in just about any other language
> > than Euphoria because of structure support. Heck, the top three
> > assembly languages I use all have structures. I find it unfortunate
> > that Windows is so reliant on these things. I find it even more so that
> > Euphoria does not directly support them.
> >
> > Trying to program API structures with Euphoria is like pulling teeth.
> > If done directly via peeks and pokes, its nice and fast. Its also hard
> > to read and maintain.
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.
> 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? If so, the coder would probably benefit
from learning a bit more about coding in general. 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.
----------------
cheers,
Derek Parnell
|
Not Categorized, Please Help
|
|
