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?

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?
>
>

"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???

"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.

"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.

"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???
> > 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.

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.

"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 ~=
operators
> 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...

"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 ~=
> operators
> > 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.

"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
string
> 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.