Passing dynamic arrays
Steven Schveighoffer
schveiguy at yahoo.com
Tue Nov 9 05:23:01 PST 2010
On Tue, 09 Nov 2010 08:14:40 -0500, Pillsy <pillsbury at gmail.com> wrote:
> Steven Schveighoffer Wrote:
>
>> On Mon, 08 Nov 2010 18:29:27 -0500, Ali Çehreli <acehreli at yahoo.com>
>> wrote:
> [...]
>> > I must be remembering an old behavior. I think appending could
>> > affect the original if it had enough capacity.
>
>> Before the array append changes were introduced (somewhere around
>> 2.040 I think?), appending to a slice that started at the beginning of
>> the memory block could affect the other data in the array. But that
>> was a memory corruption issue, somewhat different than what we
>> are talking about.
>
> Ah! This is a lot of what was confusing me about arrays; I still thought
> they had this behavior. The fact that they don't makes me a good deal
> more comfortable with them, though I still don't like the
> non-deterministic way that they may copy their elements or they may
> share structure after you append stuff to them.
As I said before, this rarely affects code. The common cases I've seen:
1. You append to an array and return it.
2. You modify data in the array.
3. You use a passed in array as a buffer, which means you overwrite the
array, and then start appending when it runs out of space.
I don't ever remember seeing:
You append to an array, then go back and modify the first few bytes of the
array.
Let's assume this is a very common thing and absolutely needs to be
addressed. What would you like the behavior to be? How can anything
different than the current behavior be reasonable?
IMO, the benefits of just being able to append to an array any time you
want without having to set up some special type far outweighs this little
quirk that almost nobody encounters. You can append to *any* array, no
matter where the data is located, or whether the data is a slice, and it
just works. I can't see how anyone would prefer another solution!
-Steve
More information about the Digitalmars-d
mailing list