[futurebasic] Re: [FB] CFDynamic

Message: < previous - next > : Reply : Subscribe : Cleanse
Home   : January 2008 : Group Archive : Group : All Groups

From: Robert Purves <listrp@...>
Date: Mon, 28 Jan 2008 20:47:53 +1300
On 28/01/2008, at 5:59 PM, Jay Reeve wrote:

>
> On Jan 27, 2008, at 5:01 PM, Brian Stevens wrote:
>
>>> Specifically text and style handles or the FB get field handle  
>>> that combines the style and text into a single bundle?
>>
>> Are you avoiding FB's dynamic arrays because of the comment in the  
>> FB Reference that  says "Dynamic arrays may not be used to  
>> dimension an array of handles"?  Don't blame you for that. It is a  
>> clear message. However,  I've used FB's dynamic array to store  
>> allocated (i.e. NewPtr) pointers (record array )  with absolutely  
>> no issues. I haven't tried storing handles with OS X.  Since I  
>> haven't looked at the dynamic array code in many months, I could be  
>> all wet here, but something tells me that the comment in the  
>> reference manual is either outdated or applies to a specific use.   
>> FBtoC implementation of dynamic arrays is different from FB's but I  
>> don't believe it would prevent you from storing handles. It is FB's  
>> implementation I haven't reviewed in a while.
>
> That caveat in the Dynamic docs, while necessary, has caused more  
> confusion than a congressional committee. What it refers to has  
> nothing to do with the ability to store a handle in a dynamic array  
> (it's just a 4-byte integer, so of course you can), but the ability  
> of FB to treat the array element as a handle. In old FB, there were  
> certain things you could do with handle arrays, to get direct access  
> to the data in the handle block. I tried to recreate this for a  
> demo, but failed. The point of the caveat, though, was that you  
> could never do that with a dynamic array.

To be specific, this works as expected in both FB and FBtoC. Handles  
get allocated then later deallocated.

begin globals
dim dynamic gMyHandles(9999) as Handle
dim as UInt32 j
dim as pointer p

for j = 0 to 99
gMyHandles(j) = fn NewHandle( 1024 )
next

//...do something with gMyHandles...

// don't 'kill dynamic' here
for j = 0 to 99
def DisposeH( gMyHandles(j) )
next
// now the Handles are gone, we can dump the array
kill dynamic gMyHandles


> You can certainly store handles in FB dynamic arrays, but you'll  
> need to either transfer them into separate handle vars for use, or  
> manually dereference them. I can't think of any reason the same  
> wouldn't be true in FBtoC.

Certain obscure dereferencing modes are mistreated by the FB compiler.  
Writing and reading a 4-bye var at the start of the Handle block gives  
the results indicated.

gMyHandles..0&(j) = j // crashes FB; illegal in FBtoC
print gMyHandles..0&(j) // wrong values in FB; illegal in FBtoC

// workaround 1
poke long [gMyHandles(j)], j // OK
print peek long ( [gMyHandles(j)] ) // OK

// workaround 2
dim as Handle h
h = gMyHandles(j)
h..0& = j // OK
print h..0& // OK

Robert P.