I'm currently doing something like this:

int[char[]] source;

...

int[char[]] dest;

foreach(k, v; source)
    dest[k] = v;

But that loop is not very high-performance.

Is there any other way to dup an AA that's better performance?  Something is telling me "no."  It would be so nice if this were a supported property for AAs, so the implementation could come up with a faster way to .dup it..

Jarrett Billingsley wrote:
> I'm currently doing something like this:
> 
> int[char[]] source;
> 
> ...
> 
> int[char[]] dest;
> 
> foreach(k, v; source)
>     dest[k] = v;
> 
> But that loop is not very high-performance.
> 
> Is there any other way to dup an AA that's better performance?  Something is telling me "no."  It would be so nice if this were a supported property for AAs, so the implementation could come up with a faster way to .dup it.. 
> 
> 

Sadly I haven't found anything either.  It seems they ought to have a direct .dup property just like fixed/variable arrays.  You can do (aa1 = aa2) but this turns out to be analogous to slicing; any later changes to aa1 also appear in aa2.

Which infers to me that AA's are referance types perchance??  At least insofar as arrays are, as a struct with a pointer?  This means there may be a "hack" to get a direct dup using memcpy, but I'm not sure how to get at that pointer safely.  Bah.

-- Chris Nicholson-Sauls

Chris Nicholson-Sauls wrote:
> Jarrett Billingsley wrote:
>> I'm currently doing something like this:
>>
>> int[char[]] source;
>>
>> ...
>>
>> int[char[]] dest;
>>
>> foreach(k, v; source)
>>     dest[k] = v;
>>
>> But that loop is not very high-performance.
>>
>> Is there any other way to dup an AA that's better performance?  Something is telling me "no."  It would be so nice if this were a supported property for AAs, so the implementation could come up with a faster way to .dup it..
>>
> 
> Sadly I haven't found anything either.  It seems they ought to have a direct .dup property just like fixed/variable arrays.  You can do (aa1 = aa2) but this turns out to be analogous to slicing; any later changes to aa1 also appear in aa2.
> 
> Which infers to me that AA's are referance types perchance??  At least insofar as arrays are, as a struct with a pointer?  This means there may be a "hack" to get a direct dup using memcpy, but I'm not sure how to get at that pointer safely.  Bah.


I think that's pretty hopeless.  AA's should have a dup property, plain and simple.  The implementation of AA's isn't specified by the spec (I don't think the performance characteristics even are), so anything you manage to get working in terms of a "raw dup" is going to be implementation-dependent.

--bb

"Chris Nicholson-Sauls" <ibisbasenji@gmail.com> wrote in message news:f19958$1a8g$1@digitalmars.com...
> Which infers to me that AA's are referance types perchance??  At least insofar as arrays are, as a struct with a pointer?  This means there may be a "hack" to get a direct dup using memcpy, but I'm not sure how to get at that pointer safely.  Bah.

They are.  The hash tables themselves are allocated on the heap, and then each element is a binary tree of heap-allocated nodes.  Making it very difficult to duplicate them, even if I use a non-portable hack.

I think I'll write a double hash table which doesn't use separate chaining. That way, I'll be able to copy all the data with "newTable.data = oldTable.data.dup".