• Jarrett Billingsley (10/10) May 01 2007 I'm currently doing something like this:
• Chris Nicholson-Sauls (8/26) May 01 2007 Sadly I haven't found anything either. It seems they ought to have a di...
• Bill Baxter (7/36) May 02 2007 I think that's pretty hopeless. AA's should have a dup property, plain
• Jarrett Billingsley (8/12) May 02 2007 They are. The hash tables themselves are allocated on the heap, and the...

"Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:

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.. 

Chris Nicholson-Sauls <ibisbasenji gmail.com> writes:

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

Bill Baxter <dnewsgroup billbaxter.com> writes:

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

"Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:

"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".