www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Slicing bug (and not just bits this time)

reply Arcane Jill <Arcane_member pathlink.com> writes:
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
Jun 12 2004
parent reply Norbert Nemec <Norbert.Nemec gmx.de> writes:
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.
Jun 13 2004
parent reply Arcane Jill <Arcane_member pathlink.com> writes:
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
Jun 13 2004
parent reply Hauke Duden <H.NS.Duden gmx.net> writes:
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
Jun 13 2004
parent reply Regan Heath <regan netwin.co.nz> writes:
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/
Jun 13 2004
parent "Vathix" <vathixSpamFix dprogramming.com> writes:
 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.
Jun 13 2004