On Wed, 16 May 2012 17:11:58 -0400, deadalnix <deadal...@gmail.com> wrote:
Le 16/05/2012 15:12, Steven Schveighoffer a écrit :
On Tue, 15 May 2012 04:42:10 -0400, deadalnix <deadal...@gmail.com>
wrote:
Le 14/05/2012 21:53, Steven Schveighoffer a écrit :
On Mon, 14 May 2012 15:30:25 -0400, deadalnix <deadal...@gmail.com>
wrote:
Le 14/05/2012 16:37, Steven Schveighoffer a écrit :
Note that [] is a request to the runtime to build an empty array.
The
runtime detects this, and rather than consuming a heap allocation to
build nothing, it simply returns a null-pointed array. This is 100%
the
right decision, and I don't think anyone would ever convince me (or
Andrei or Walter) otherwise.
Obviously this is the right thing to do !
The question is why an array of length 0 isn't nulled ? It lead to
confusing semantic here, and can keep alive memory that can't be
accessed.
int[] arr;
arr.reserve(10000);
assert(arr.length == 0);
-Steve
The length isn't set to 0 here. You obviously don't want that to be
nulled.
The assert disagrees with you :)
-Steve
The length IS 0. It IS 0 before the call to reserve. It is never SET to
0.
OK, so it's allowed to be 0 and not-null. doesn't this lead to the
confusing semantics you were talking about?
What about this?
int[] arr;
arr.reserve(10000);
int[] arr2 = [1,2,3];
arr2 = arr; // now length has been *set* to 0, should it also be nulled?
But I want arr2 and arr to point at the same thing, maybe I'm not using
arr anymore. Maybe I returned it from a function, and I no longer have
access to arr.
-Steve
