Digital Mars - D - comparing strings (and arrays)

↑ ↓ ← → "Pavel Minayev" <evilone omen.ru> writes:

How exactly do I compare two strings in D? The following
doesn't work:

    char[] s = "const";
    if (s == "const")
        printf("ok\n");
    if (s[] == "const")
        printf("ok\n");

Yes there's an strcmp() but it works only with ASCIIZ
strings...

Am I missing something?

Dec 12 2001

↑ ↓ ← → "Walter" <walter digitalmars.com> writes:

No, you're not missing something, D is! A set of string library routines
needs to be written! -Walter

"Pavel Minayev" <evilone omen.ru> wrote in message
news:9v7g3r$1n5j$1 digitaldaemon.com...
 How exactly do I compare two strings in D? The following
 doesn't work:

     char[] s = "const";
     if (s == "const")
         printf("ok\n");
     if (s[] == "const")
         printf("ok\n");

 Yes there's an strcmp() but it works only with ASCIIZ
 strings...

 Am I missing something?

Dec 12 2001

↑ ↓ ← → "Pavel Minayev" <evilone omen.ru> writes:

"Walter" <walter digitalmars.com> wrote in message
news:9v817i$23aj$1 digitaldaemon.com...

 No, you're not missing something, D is! A set of string library routines
 needs to be written! -Walter


You mean that strings are to be compared with functions
rather than with operators???

Dec 12 2001

↑ ↓ ← → "Walter" <walter digitalmars.com> writes:

"Pavel Minayev" <evilone omen.ru> wrote in message
news:9v83oq$24uf$1 digitaldaemon.com...
 "Walter" <walter digitalmars.com> wrote in message
 news:9v817i$23aj$1 digitaldaemon.com...

 No, you're not missing something, D is! A set of string library routines
 needs to be written! -Walter


 You mean that strings are to be compared with functions
 rather than with operators???


At the moment, yes. I haven't fully explored doing it with <, <=, ==, !=, >,
= yet.

Dec 12 2001

↑ ↓ ← → "Pavel Minayev" <evilone omen.ru> writes:

"Walter" <walter digitalmars.com> wrote in message
news:9v84iq$25n5$1 digitaldaemon.com...

 You mean that strings are to be compared with functions
 rather than with operators???


 At the moment, yes. I haven't fully explored doing it with <, <=, ==, !=,
,
= yet.




I meant the "generic D" rather than current implementation...
Of course, it can't just work this simple: == and friends are
already defined for pointers.

This raises an interesting point I've had in mind for a long
time already. Have you considered making strings a distinct
data type, something like a sub-class of normal array, with
equality, + and - operators overloaded and some built-in
functions like substr() and trim(). I never saw any point in
trying to fit strings into existing language mechanisms, since
programmers usually tend to treat them as a special data type.
Looking at the modern languages (VB, Pascal, Java, C#), we see
that they all treat string as distinct data type - probably
because it's _more_ than an array of chars, in terms of
functionality, not physical form.

Dec 12 2001

↑ ↓ ← → "Walter" <walter digitalmars.com> writes:

"Pavel Minayev" <evilone omen.ru> wrote in message
news:9v89v5$29l5$1 digitaldaemon.com...
 "Walter" <walter digitalmars.com> wrote in message
 news:9v84iq$25n5$1 digitaldaemon.com...
 You mean that strings are to be compared with functions
 rather than with operators???






,
= yet.




 Of course, it can't just work this simple: == and friends are
 already defined for pointers.


Yes, that's just the trouble.

 This raises an interesting point I've had in mind for a long
 time already. Have you considered making strings a distinct
 data type, something like a sub-class of normal array, with
 equality, + and - operators overloaded and some built-in
 functions like substr() and trim(). I never saw any point in
 trying to fit strings into existing language mechanisms, since
 programmers usually tend to treat them as a special data type.
 Looking at the modern languages (VB, Pascal, Java, C#), we see
 that they all treat string as distinct data type - probably
 because it's _more_ than an array of chars, in terms of
 functionality, not physical form.


That's why char[] is a distinct type from byte[] and the ~ and ~= operators
exist. I came to disfavor Java's String class, because it is both
inefficiently implementable and too specialized.

Dec 12 2001

↑ ↓ ← → "Pavel Minayev" <evilone omen.ru> writes:

"Walter" <walter digitalmars.com> wrote in message
news:9v9fuu$2vop$1 digitaldaemon.com...

 That's why char[] is a distinct type from byte[] and the ~ and ~=


 exist. I came to disfavor Java's String class, because it is both
 inefficiently implementable and too specialized.


I'm not speaking of classes here. Implementing string as class adds
too much overhead, indeed. I proposed to make it a built-in type,
like in Pascal or BASIC, with all functionality of char[], but
operators overloaded for different purposes (so == compares strings
themselves rather than pointers, + concatenates, - removes substring
etc). So when you want to have array of chars, you use char[], and
if you want to have a _string_, you use string.

As for distinction between char and byte... my POV here is:

    byte - an integer -128..127
    ubyte - an integer 0..255
    char - a symbol
    char[] - array of symbols
    string - guess =)

So ubyte and char, while basically being the same, _represent_
different things. In fact, char could be a typedef for byte...

Dec 13 2001

↑ ↓ ← → "Walter" <walter digitalmars.com> writes:

"Pavel Minayev" <evilone omen.ru> wrote in message
news:9v9oe4$4aa$1 digitaldaemon.com...
 "Walter" <walter digitalmars.com> wrote in message
 news:9v9fuu$2vop$1 digitaldaemon.com...

 That's why char[] is a distinct type from byte[] and the ~ and ~=


 exist. I came to disfavor Java's String class, because it is both
 inefficiently implementable and too specialized.


 I'm not speaking of classes here. Implementing string as class adds
 too much overhead, indeed. I proposed to make it a built-in type,
 like in Pascal or BASIC, with all functionality of char[], but
 operators overloaded for different purposes (so == compares strings
 themselves rather than pointers, + concatenates, - removes substring
 etc). So when you want to have array of chars, you use char[], and
 if you want to have a _string_, you use string.

 As for distinction between char and byte... my POV here is:

     byte - an integer -128..127
     ubyte - an integer 0..255
     char - a symbol
     char[] - array of symbols
     string - guess =)

 So ubyte and char, while basically being the same, _represent_
 different things. In fact, char could be a typedef for byte...


I think of char as a typedef for ubyte, after all, what good are negative
characters <g>? That's another thing with C that I think just causes
trouble - the signed char type.

The only time I see that char[] doesn't do just what you'd want with string
is the == and != operators.

Dec 14 2001

↑ ↓ ← → "Pavel Minayev" <evilone omen.ru> writes:

"Walter" <walter digitalmars.com> wrote in message
news:9vdebf$2bma$2 digitaldaemon.com...

 The only time I see that char[] doesn't do just what you'd want with


 is the == and != operators.


If string would be a distinct type, + and - could be also
overloaded. And built-in methods like toupper(), tolower(),
trim(), find() etc could be added.

Dec 14 2001