Has truth of arrays always acted like this?
Bill Baxter
dnewsgroup at billbaxter.com
Sun Oct 14 22:05:17 PDT 2007
> "Mike Parker" <aldacron71 at yahoo.com> wrote in message
> news:feuj8s$1kjt$1 at digitalmars.com...
>> Bill Baxter wrote:
>>> Bill Baxter wrote:
>>>> I could have sworn there was a big discussion just recently about how
>>>> "null" and "empty" were the same thing with D arrays and some people
>>>> were arguing that should change. But at least with the most recent D
>>>> v1.022, it seems the truth value of uninitialized and empty arrays *are*
>>>> different. Has it always been that way?
>>> I think maybe the discussion I was remembering was about comparison with
>>> null. Indeed (a==null) is true for both uninitialized *and* length==0
>>> arrays.
>>>
>>> That seems completely backwards to me. If anything, a==null should be
>>> the one that checks if a has a buffer allocated at all, and if(a) should
>>> be the one that checks for any form of emptiness.
>>>
>>> Barring that, they should just behave the same.
>>>
>>> --bb
>> I recall a recent discussion specifically about empty vs. null strings,
>> i.e. an empty string ("") is equivalent to a null string:
>>
>> char[] s1 = "";
>> char[] s2 = null;
>>
>> if(s1 == s2) writefln("equal");
>>
>> This will evaluate to true.
>
Kris wrote:
> Well, I sure hope that /never/ happens. A null is a null (the array
.ptr and
> .length are both zero), while an empty string is perfectly valid.
Hope what never happens?
> tip: faster way (on 32bit platforms) to check for null array is to
test the
> .ptr only, since it's 32 bits rather than 64.
size_t is 32 bits on a 32 bit platform too.
--bb
More information about the Digitalmars-d-learn
mailing list