D - comparing strings (and arrays)
- Pavel Minayev (10/10) Dec 12 2001 How exactly do I compare two strings in D? The following
- Walter (4/14) Dec 12 2001 No, you're not missing something, D is! A set of string library routines
- Pavel Minayev (4/6) Dec 12 2001 You mean that strings are to be compared with functions
- Walter (3/10) Dec 12 2001 At the moment, yes. I haven't fully explored doing it with <, <=, ==, !=...
- Pavel Minayev (16/21) Dec 12 2001 I meant the "generic D" rather than current implementation...
- Walter (7/28) Dec 12 2001 !=,
- Pavel Minayev (18/21) Dec 13 2001 operators
- Walter (7/28) Dec 14 2001 I think of char as a typedef for ubyte, after all, what good are negativ...
- Pavel Minayev (6/8) Dec 14 2001 string
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
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
"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! -WalterYou mean that strings are to be compared with functions rather than with operators???
Dec 12 2001
"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...At the moment, yes. I haven't fully explored doing it with <, <=, ==, !=, >,No, you're not missing something, D is! A set of string library routines needs to be written! -WalterYou mean that strings are to be compared with functions rather than with operators???= yet.
Dec 12 2001
"Walter" <walter digitalmars.com> wrote in message news:9v84iq$25n5$1 digitaldaemon.com...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. 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.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> 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 <, <=, ==,Yes, that's just the trouble.,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.= yet.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. 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
"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 ~=operatorsexist. 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
"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...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.That's why char[] is a distinct type from byte[] and the ~ and ~=operatorsexist. 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 14 2001
"Pavel Minayev" <evilone omen.ru> "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 withstringis 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