On 12 Feb 2008 at 3:12, Przemyslaw Czerpak wrote: > I want to reduce API functions which may cause internal errors > in different places when are used in wrong way. And hb_gcLock()/ > hb_gcUnlock() are potentially such functions. Now I do not see any > code which may need it as long as it does not use some thicks like > unknown for GC HB_ITEMs.
OK, I can agree on such restictions however we will have to document that the pointer allocated with hb_gcAlloc() have to be attached using hb_gcAttach() function to some item - the item have to be allocated using hb_itemNew(). Or alternatively we can use gcAlloc/gcAttach internally in VM/RTL but 3-rd party code will have to use a wrapper called for example hb_itemNewGCPtr( size, destructor ) that will replace hb_itemPutPtrGC() > Array reallocation should not be a problem. Now we do not have any > preallocation code for arrays but it can be and for sure will be added > in the future. xHarbour already has such feature. it's few lines only. > You can even implement such feature yourself for SQL RDD by keeping > index to free raw in array in additional variable and multiple the > array size by 2 when the pointer reach limit. The cost of reallocation > will be n*log2(n)/2 where n is maximum array size - unimportant if > you compere it to cost of row creation. You can also keep raws in > items allocated by hb_itmeNew() and create list of such items though > here the cost will be bigger but you ill not need continuous memory > block. IMHO everything is better then touching item internals. OK, you can remove it, I can just use an array of arrays of rows which probably will be a good compromise between the GC and the performance. Regards, Ryszard _______________________________________________ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
