Moving structs containing strings ...

[kris]

Bob W wrote:
> "Derek Parnell" <derek at psych.ward> wrote in message 
> news:op.s8hhktza6b8z09 at ginger.vic.bigpond.net.au...
> 
>>On Mon, 24 Apr 2006 08:44:57 +1000, Bob W <nospam at aol.com> wrote:
>>
>>For a workaround,
>>
>>   with (arr[0]) { idz[]="ab\0";  id=idz[0..2];  val=101; }
>>   with (arr[1]) { idz[]="cd\0";  id=idz[0..2];  val=102; }
>>   with (arr[2]) { idz[]="ef\0";  id=idz[0..2];  val=103; }
>>
>>replace those lines with
>>
>>  with (arr[0]) { idz[]="ab\0";  id=idz[0..2].dup;  val=101; }
>>  with (arr[1]) { idz[]="cd\0";  id=idz[0..2].dup;  val=102; }
>>  with (arr[2]) { idz[]="ef\0";  id=idz[0..2].dup;  val=103; }
>>
>>
>>-- 
>>Derek Parnell
>>Melbourne, Australia
> 
> 
> Thanks for your suggestion. But I am more keen to know
> why the example mentioned in my post is not producing
> the desired results than in applying a workaround.
> 
> If this question remains unanswered I'll have to revert
> to using pointers for the application which initially has
> produced these erroneus results. Using '.dup' several
> million times would probably bring my system to a
> standstill. I might be wrong with this guess, however ...
> 
> 
> 


eeeewe :)

The 'id' slices are mapped to absolute addresses, and thus are mapped to 
specific addresses within the array.

When you remove array element 0 and compress the array, those addresses 
are not updated, and you end up with the result shown. After 
compression, the 'id' slice for val:102 is still pointing at where it 
used to live, although the original "cd" text has now been overwritten 
with the val:103 "ef" text instead :)

The 'id' slice for val:103 is actually still pointing to its original 
location, which is now /past/ the end of the array (hehe).

One solution is to adjust each 'id' slice when you compress or otherwise 
adjust the array content. Wouldn't you have to do this with pointers also?

- Kris