Re: A community Windows binding

[CBFalconer <cbfalconer@yahoo.com>]

Stephen Leake wrote:
> Jeffrey Carter <spam@spam.com> writes:
> 
>> Callbacks and dispatching are essentially the same thing in a
>> windowing system. You have to write little pieces of code that
>> can be invoked in any order at any time outside your control.
>> You have to use global variables extensively for these little
>> pieces of code to communicate. The code is difficult to read
>> because you have to understand all these little pieces to
>> understand any part of the software.
> 
> In Windex, GWindows, CLAW, and GtkAda, each "little piece of
> code" has as a parameter the user window type. That type stores
> all the information needed; no global variables are necessary.
> 
> I can (with a lot of effort to suppress my normal style :)
> write messy, hard to read code in Windex, using global
> variables. But it's certainly not required.

I disagree that callbacks and dispatching are essentially the same,
unless you take the view that the OS and all its processes are one
large program, which in turn falls down in the presence of
multi-processors.  To me, callbacks are simply a way of customizing
another piece of software, much as (in C) qsort is customized by a
comparison function.  Dispatching has to do with selecting a
process (or thread) to execute.

As an example, there follows an extract from my hashlib.h (complete
package available on my site), which has no data space of its own. 
The hashinit function allocates space in the callers data space, in
which it records the location of various customizing functions (all
typedef'd in the same header).  The package is fully re-entrant,
except when calling malloc, etc.  All other calls pass back the
pointer to that space, much like the 'this' pointer in C++.  In
many ways hshinit and hshkill are equivalent to fopen and fclose.

Not really being familiar with Ada, but lurking here, this is the
best I can do for an example of so-called callback functions.  This
package was, among other things, originally intended to be an
example of OO techniques in C, and a testbed for hashing
functions.  Note that nothing spells out the table size.

/* initialize and return a pointer to the data base */
hshtbl *hshinit(hshfn hash, hshfn rehash,
                hshcmpfn cmp,
                hshdupfn dupe, hshfreefn undupe,
                int      hdebug);

/* 1------------------1 */

/* destroy the data base. Accepts NULL and does nothing */
void   hshkill(hshtbl *master);

/* 1------------------1 */

/* find an existing entry. NULL == notfound */
void * hshfind(hshtbl *master, void *item);

/* 1------------------1 */

/* delete an existing entry. NULL == notfound      */
/* Disposal of the storage returned by hshdelete   */
/* (originally created by hshdupfn) is up to the   */
/* application. It is no longer managed by hashlib */
/* It will usually be disposable by hshfreefn().   */
void * hshdelete(hshtbl *master, void *item);

/* 1------------------1 */

/* insert an entry.  NULL == failure, else item */
void * hshinsert(hshtbl *master, void *item);

-- 
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
   <http://cbfalconer.home.att.net>  USE worldnet address!