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