arrays: if(null == [ ])

Steven Schveighoffer schveiguy at yahoo.com
Wed May 16 14:15:34 PDT 2012


On Wed, 16 May 2012 17:11:58 -0400, deadalnix <deadalnix at gmail.com> wrote:

> Le 16/05/2012 15:12, Steven Schveighoffer a écrit :
>> On Tue, 15 May 2012 04:42:10 -0400, deadalnix <deadalnix at gmail.com>  
>> wrote:
>>
>>> Le 14/05/2012 21:53, Steven Schveighoffer a écrit :
>>>> On Mon, 14 May 2012 15:30:25 -0400, deadalnix <deadalnix at 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


More information about the Digitalmars-d mailing list