>
> Now the another guideline:
>
> Many functions of WINAPI accept structures as their
> parameters. Should we use them to be compatible with
> WINAPI exactly or should we use arrays?
> Both approaches have merits and demerits.
> I personally propose to use STRUCTURES where ever
> possible. What group says?
Structures would be nice, but I'm not sure if there is
a way to implement it cleanly and in a portable way.
What we have in xhb.lib doesn't look like one.
My vote to arrays for now.
Another point where implementations differ, is handling
handles / pointers. We should definitely allow for raw
pointers (parptr) and pointers as numbers (parnint), and
where it makes sense it'd be good to consider to also allow
pointers with automatic destructors (parptrGC) to make
sure app code cannot leak them. Functions returning
pointer should use retptr (or retptrGC), and try to avoid
retnint.
--- skeleton code for automatic destructor:
static HB_GARBAGE_FUNC( win_<T>_release )
{
void ** ph = ( void ** ) Cargo;
/* Check if pointer is not NULL to avoid multiple freeing */
if( ph && *ph )
{
/* Destroy the object */
FUNCTION_CALL_TO_DESTROY_AND_FREE_OBJECT( ( <T> ) *ph );
/* set pointer to NULL to avoid multiple freeing */
*ph = NULL;
}
}
---
--- skeleton code for handle parameter retrieval:
static <T> win_<T>_par( int iParam )
{
if( ISNUM( iParam ) )
return ( <T> ) ( HB_PTRDIFF ) hb_parnint( iParam );
else
{
void ** ph = ( void ** ) hb_parptrGC( win_<T>_release, iParam );
return ph ? ( <T> ) * ph : hb_parptr( iParam );
}
}
---
--- skeleton code to return garbage collected pointer:
{
void ** ph = ( void ** ) hb_gcAlloc( sizeof( <T> * ), win_<T>_release );
*ph = ( void * ) FUNCTION_CALL_TO_ALLOCATE_OBJECT( ... );
hb_retptrGC( ph ); OR hb_storptrGC( ph, ... );
}
---
Brgds,
Viktor
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
