Thread overview | ||||||||
---|---|---|---|---|---|---|---|---|
|
June 13, 2004 Slicing bug (and not just bits this time) | ||||
---|---|---|---|---|
| ||||
Try this:
> ubyte s[10];
> ubyte[] t = s[0..0];
> if (t)
> {
> printf("t not empty\n");
> }
The problem is that expression s[i..j] yeilds a slice which is not well formed. It has a length field of zero, but a pointer field which is non-zero (actually the address of s[i]. Thus, expressions like if (s[i..j]) will NOT test as false if i == j.
The current workaround is to repace "if (t)" with "if (t.length != 0)".
Arcane Jill
|
June 13, 2004 Re: Slicing bug (and not just bits this time) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Arcane Jill | Arcane Jill wrote:
> Try this:
>
>> ubyte s[10];
>> ubyte[] t = s[0..0];
>> if (t)
>> {
>> printf("t not empty\n");
>> }
>
> The problem is that expression s[i..j] yeilds a slice which is not well formed. It has a length field of zero, but a pointer field which is non-zero (actually the address of s[i]. Thus, expressions like if (s[i..j]) will NOT test as false if i == j.
>
> The current workaround is to repace "if (t)" with "if (t.length != 0)".
I'm not sure this is a bug or a feature. Of course, a zero-length array reference cannot be indexed without getting an out-of-range exception. But I'm not really sure whether it should be considered identical to null.
|
June 13, 2004 Re: Slicing bug (and not just bits this time) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Norbert Nemec | In article <cahmcb$92$1@digitaldaemon.com>, Norbert Nemec says... > >> The problem is that expression s[i..j] yeilds a slice which is not well formed. It has a length field of zero, but a pointer field which is non-zero (actually the address of s[i]. Thus, expressions like if (s[i..j]) will NOT test as false if i == j. >> >> The current workaround is to repace "if (t)" with "if (t.length != 0)". > >I'm not sure this is a bug or a feature. Of course, a zero-length array reference cannot be indexed without getting an out-of-range exception. But I'm not really sure whether it should be considered identical to null. Except that according to the D website at http://www.digitalmars.com/d/cppstrings.html, it says explicitly, and I quote: >Checking For Empty Strings >C++ strings use a function to determine if a string is empty: > > string str; > if (str.empty()) > // string is empty > >In D, an empty string is just null: > > char[] str; > if (!str) > // string is empty So either the documentation is in error, or it's a bug. Arcane Jill |
June 13, 2004 Re: Slicing bug (and not just bits this time) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Arcane Jill | Arcane Jill wrote:
> In article <cahmcb$92$1@digitaldaemon.com>, Norbert Nemec says...
>
>>>The problem is that expression s[i..j] yeilds a slice which is not well
>>>formed. It has a length field of zero, but a pointer field which is
>>>non-zero (actually the address of s[i]. Thus, expressions like if
>>>(s[i..j]) will NOT test as false if i == j.
>>>
>>>The current workaround is to repace "if (t)" with "if (t.length != 0)".
>>
>>I'm not sure this is a bug or a feature. Of course, a zero-length array
>>reference cannot be indexed without getting an out-of-range exception. But
>>I'm not really sure whether it should be considered identical to null.
>
>
> Except that according to the D website at
> http://www.digitalmars.com/d/cppstrings.html, it says explicitly, and I quote:
>
>
>>Checking For Empty Strings
>>C++ strings use a function to determine if a string is empty:
>>
>> string str;
>> if (str.empty())
>> // string is empty
>>
>>In D, an empty string is just null:
>>
>> char[] str;
>> if (!str)
>> // string is empty
>
>
> So either the documentation is in error, or it's a bug.
> Arcane Jill
Hmmm. If this is the case then I think it is a mistake. A null string is different from an empty string. One means the absence of a string and the other means that the string has length 0.
This is an important difference. For example, passing null for a string argument usually means "use the default". That kind of semantics would be impossible if empty strings are also valid values.
Hauke
|
June 13, 2004 Re: Slicing bug (and not just bits this time) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Hauke Duden | On Sun, 13 Jun 2004 19:39:48 +0200, Hauke Duden <H.NS.Duden@gmx.net> wrote: > Arcane Jill wrote: >> In article <cahmcb$92$1@digitaldaemon.com>, Norbert Nemec says... >> >>>> The problem is that expression s[i..j] yeilds a slice which is not well >>>> formed. It has a length field of zero, but a pointer field which is >>>> non-zero (actually the address of s[i]. Thus, expressions like if >>>> (s[i..j]) will NOT test as false if i == j. >>>> >>>> The current workaround is to repace "if (t)" with "if (t.length != 0)". >>> >>> I'm not sure this is a bug or a feature. Of course, a zero-length array >>> reference cannot be indexed without getting an out-of-range exception. But >>> I'm not really sure whether it should be considered identical to null. >> >> >> Except that according to the D website at >> http://www.digitalmars.com/d/cppstrings.html, it says explicitly, and I quote: >> >> >>> Checking For Empty Strings >>> C++ strings use a function to determine if a string is empty: >>> >>> string str; >>> if (str.empty()) >>> // string is empty >>> >>> In D, an empty string is just null: >>> >>> char[] str; >>> if (!str) >>> // string is empty >> >> >> So either the documentation is in error, or it's a bug. >> Arcane Jill > > Hmmm. If this is the case then I think it is a mistake. A null string is different from an empty string. One means the absence of a string and the other means that the string has length 0. Agreed, we need both. > This is an important difference. For example, passing null for a string argument usually means "use the default". That kind of semantics would be impossible if empty strings are also valid values. I think it is logical that s[0..0] returns an empty string and not null. I think the docs need an update. The existing example is good as a test for null but it should be noted that empty strings can exist and how to get them. if (!str) //tests for null if (str.length == 0) //tests for null and empty Regan. -- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/ |
June 13, 2004 Re: Slicing bug (and not just bits this time) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Regan Heath | > > Hmmm. If this is the case then I think it is a mistake. A null string is different from an empty string. One means the absence of a string and the other means that the string has length 0.
>
> Agreed, we need both.
I always test s.length to see if it contains 0 elements. When I want to see if it's null I use s === null . if(s) was never reliable for me.
|
Copyright © 1999-2021 by the D Language Foundation