Bob W wrote:
> "Derek Parnell" <derek@psych.ward> wrote in message news:c7u4nwvom7ca$.o0vru71wqxwe.dlg@40tude.net...
>> Another solution is to recalculate the addresses of the id strings after
>> changing the length ...
>>
>>  arr=arr[0..2];   // adjust length
>>  foreach( inout Sc s; arr)
>>      s.id = s.idz[0..s.id.length];
>>
> 
> I'll gladly accept this as a solution, because it will
> utilize existing strings within the structs-array.
> 
> The workaround you have posted earlier allocates
> memory and duplicates strings one by one. That is
> something I would not want to try in real-world
> applications due to obvious reasons.

How about defining the struct like this:

struct Sc { uint val;  char[3] idz;  char[] id() { return idz[0..3]; } }

This turns 'id' into a property instead of a field. This might be slightly slower*, but has several advantages:

- It will always return the current string without needing manual updates.
- It doesn't allocate.
- It removes the need to initialize 'id' separately.
- Added bonus: Sc.sizeof is halved. (goes from 16 bytes to 8 bytes)


*) Not necessarily though, it may well be optimized out.

"Frits van Bommel" <fvbommel@REMwOVExCAPSs.nl> wrote in message news:e2iqkp$2fvl$1@digitaldaemon.com...
>
> How about defining the struct like this:
>
> struct Sc { uint val;  char[3] idz;  char[] id() { return idz[0..3]; } }
>
> This turns 'id' into a property instead of a field. This might be slightly slower*, but has several advantages:

No idea what slightly slower means to you, but I can
guarantee you that with indirect string access you
won't even get to 50% of the original speed.


> - It will always return the current string without needing manual updates.

I need direct access to the strings, due to performance
reasons. Therefore I do not mind the updates whenerver
they are required.


> - It doesn't allocate.

This would be unacceptable anyway.


> - It removes the need to initialize 'id' separately.

You are referring to the sample which has those
convenient constant length strings. My application
does not work this way, however. I'd have to
have some basic initialisation first in order to
get quicker access later.


> - Added bonus: Sc.sizeof is halved. (goes from 16 bytes to 8 bytes)

I guess most of us have 1 or 2GB installed these days, true?


Don't get me wrong. Your idea would be definitely
worthwhile considering for other applications. But it
just does not fit my current requirements.