On Tue, 12 Feb 2008, Ryszard Glab wrote: > 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()
Sometimes user may want to initialize allocated block body before attaching it so separated functions seems to be better. It's also possible that he decide to free allocating block with hb_gcFree() instead of attaching it due to some new conditions f.e. errors which may appear during initialization. In current core code hb_gcFree() is not used at all. If we add above modifications then we can also check if hb_gcFree() is executed with locked block to catch possible programmer mistakes. Also allocating and freeing new item can cause some additional overhead and make some code more complicated then necessary. > > 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. I do not want to remove it yet because I can imagine some interesting functionality for it without touching HB_ITEM internals though it will be necessary to add one additional function for it: hb_gcMark( pGCBlock ). And this is the reason why I asked about it. Does anyone created some code which uses extensively pure GC blocks with cross references attached to our GC system by hb_gcRegisterSweep() and his own hb_gcMark() function? Marek you said that you are using mark/sweep functions extensively. Is it only for marking external HB_ITEMs or for sth else. best regards, Przemek _______________________________________________ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
