Moving structs containing strings ...

kris foo at
Sun Apr 23 19:05:27 PDT 2006

Bob W wrote:
> "Derek Parnell" <derek at psych.ward> wrote in message 
> news:op.s8hhktza6b8z09 at
>>On Mon, 24 Apr 2006 08:44:57 +1000, Bob W <nospam at> 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

More information about the Digitalmars-d-bugs mailing list