Inability to dup/~ for const arrays of class objects

[Peter Williams]

On 31/05/13 23:58, Steven Schveighoffer wrote:
> On Fri, 31 May 2013 00:48:47 -0400, Peter Williams
>>
>> That makes programming much easier, doesn't it.  I'll just avoid it by
>> using:
>>
>> a = a ~ b;
>>
>> instead of:
>>
>> a ~= b;
>
> If you care nothing for performance, this certainly is a way to go.
>
>> where I think it might be an issue or is that broken too?
>
> This is a conservative "always reallocate" methodology, it should work
> just like you allocated a new array to hold a and b.

That's what I assumed.  I'm still getting used to the idea that "a <op>= 
b" isn't just a shorthand for "a = a <op> b".

>
> If a is frequently large, and b is frequently small, you will kill your
> performance vs. a ~= b.

I doubt that I'll be doing it often enough (i.e. only when I think that 
it's an issue) for it to matter.  The only time I have two variables for 
the same array is when I pass one to a function as a parameter and if 
I'm intending to modify it in the function I'll pass it by reference so 
that there's no gotchas.

I do like the idea that "~=" is generally cheap as it potentially makes 
building lists easy (is there any need for the singly linked list in D?) 
and I may modify some of my code.  I've been allocating arrays using 
"new array[size]" where I know that "size" will be the max needed but 
that it may be too much (i.e. throwing away duplicates) inserting into 
the array and then adjusting "length" to whatever I used.  In the case, 
where it's highly likely that the whole array will fit in a page I might 
as well allocate an empty array and use "+=".  NB there's only one copy 
of the array.

Peter