Inability to dup/~ for const arrays of class objects

Steven Schveighoffer schveiguy at yahoo.com
Mon Jun 3 07:57:40 PDT 2013


On Fri, 31 May 2013 21:04:47 -0400, Peter Williams  
<pwil3058 at bigpond.net.au> wrote:

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

It is if you don't care about where it lands :)  I understand that in some  
cases, it's important or desirable to dictate whether extension-in-place  
is used or not, but in most cases, you don't care, you just want to change  
an array to contain more data.

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

The only real gotchas come if you append *and then* modify the original  
data.  If you append *after* modifying the original data, or don't modify  
the original data, then there is no issue.  If you only ever have one  
reference to the array data, there is no issue.

There really are very few cases where appending can cause curious  
behavior.  For the most part, it's undetected.

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

You can .reserve the space that you need ahead of time.  Then appending  
will always deterministically go into the reserved block, and won't  
reallocate.  This should be relatively quick.  It's not as quick as  
pre-allocating the entire array and then writing the data directly -- you  
still need calls into the runtime for appending.

The appending feature of D arrays/slices is intended to be "good enough"  
for most usages, not horrendously slow, but also not super-optimized for  
specific purposes.

And yes, we still need linked lists, arrays are good for appending, but  
not inserting :)

-Steve


More information about the Digitalmars-d mailing list