Re: [Harbour] Study about return GCs generic.

2010-01-12 Thread Xavi
Hi Przemek, Yes, it is. Anyhow accepting unknown pointer items is also wrong and I do not want to add to core code functions which are not usable for code which cleanly checks all pointer items. Yes I see it. Thank you for teach me to see. It can be done in few different ways, i.e. you can a

Re: [Harbour] Study about return GCs generic.

2010-01-12 Thread Przemysław Czerpak
On Tue, 12 Jan 2010, Xavi wrote: Hi, > I'm trying to mix both versions but when the address of the HB_GC_FUNCS > is not available I don't know how to do it. > Yes, thank you Przemek, I can do the same with .- > HANDLE wapi_par_HANDLE( int iParam ) > { >PHB_ITEM pItem = hb_param( iParam, HB_IT

Re: [Harbour] Study about return GCs generic.

2010-01-11 Thread Xavi
Thank you very much Mindaugas, I'm trying to mix both versions but when the address of the HB_GC_FUNCS is not available I don't know how to do it. Yes, thank you Przemek, I can do the same with .- HANDLE wapi_par_HANDLE( int iParam ) { PHB_ITEM pItem = hb_param( iParam, HB_IT_POINTER );

Re: [Harbour] Study about return GCs generic.

2010-01-11 Thread Przemysław Czerpak
On Mon, 11 Jan 2010, Mindaugas Kavaliauskas wrote: Hi, > From Xavi's sample: > >HANDLE wapi_par_HANDLE( int iParam ) > >{ > > void ** ph = ( void ** ) hb_parptrGC( NULL, iParam ); > > > > return (ph ? ( HANDLE ) *ph : ( HANDLE ) hb_parptr( iParam )); > >} > I guess, he is trying to avoid logi

Re: [Harbour] Study about return GCs generic.

2010-01-11 Thread Mindaugas Kavaliauskas
Hi, Sorry but I do not see any problem so I cannot advice you any solution. You have to precisely define what you need and why. From Xavi's sample: HANDLE wapi_par_HANDLE( int iParam ) { void ** ph = ( void ** ) hb_parptrGC( NULL, iParam ); return (ph ? ( HANDLE ) *ph : ( HANDLE ) hb_

Re: [Harbour] Study about return GCs generic.

2010-01-11 Thread Przemysław Czerpak
On Mon, 11 Jan 2010, Xavi wrote: Hi, > ... Ok, I can assume so. > > return ( HANDLE ) ( ph ? *ph : NULL ); > > But this assumes that it's always GC. > Perhaps we need an API function .- It does not assume anything. It only accepts any pointer items but I do not see any difference in accep

Re: [Harbour] Study about return GCs generic.

2010-01-11 Thread Xavi
Hi Przemek, The ides of hb_itemGetPtrGC() is to _NOT_ make such things and return _ONLY_ pointers which are exactly the requested type. ... Ok, I can assume so. return ( HANDLE ) ( ph ? *ph : NULL ); But this assumes that it's always GC. Perhaps we need an API function .- BOOL hb_i

Re: [Harbour] Study about return GCs generic.

2010-01-10 Thread Przemysław Czerpak
On Mon, 11 Jan 2010, Xavi wrote: Hi, > IMHO the next changes in the functions hb_parptrGC and hb_itemGetPtrGC .- > void * hb_itemGetPtrGC( PHB_ITEM pItem, const HB_GC_FUNCS * pFuncs ) > { >HB_TRACE(HB_TR_DEBUG, ("hb_itemGetPtrGC(%p,%p)", pItem, pFuncs)); >if( pItem && HB_IS_POINTER( pItem

Re: [Harbour] Study about return GCs generic.

2010-01-10 Thread Xavi
Hi Viktor, The case where pFunc is NULL seems to be covered already by existing pure hb_parptr() (and friend) functions. To me seems to not is covered because we need another function to know if it's collect or direct and take reference or address. return (ph ? ( HANDLE ) *ph : ( HANDLE ) ph

Re: [Harbour] Study about return GCs generic.

2010-01-10 Thread Viktor Szakáts
Hi Xavi, > IMHO the next changes in the functions hb_parptrGC and hb_itemGetPtrGC .- > > void * hb_parptrGC( const HB_GC_FUNCS * pFuncs, int iParam ) > { > ... > if( HB_IS_POINTER( pItem ) && pItem->item.asPointer.collect ) > { > if( pFuncs ) >return (hb_gcFuncs( pIt

[Harbour] Study about return GCs generic.

2010-01-10 Thread Xavi
Hi All, IMHO the next changes in the functions hb_parptrGC and hb_itemGetPtrGC .- void * hb_parptrGC( const HB_GC_FUNCS * pFuncs, int iParam ) { HB_STACK_TLS_PRELOAD HB_TRACE(HB_TR_DEBUG, ("hb_parptrGC(%p,%d)", pFuncs, iParam)); if( iParam >= -1 && iParam <= hb_pcount() ) { P