ftp://www.digitalmars.com/dmdalpha3.zip

Fixed a lot of bugs regarding arrays and strings.

Check out strings.d, the D string runtime library functions. It makes much use of array slicing and unit tests.

-Walter

"Walter" <walter@digitalmars.com> wrote in message news:9vrg2r$2q8m$1@digitaldaemon.com...
> ftp://www.digitalmars.com/dmdalpha3.zip
>
> Fixed a lot of bugs regarding arrays and strings.
>
> Check out strings.d, the D string runtime library functions. It makes much use of array slicing and unit tests.

I might be mistaken... but isn't it supposed to be alpha 4
(since alpha 3 was released several days ago already)? =)

Heh,

Seems like you've forgot to include the new phobos.lib
into the archive: it's dated 12/16 and has all the new
stuff like string functions missing.

By the way, a question about strings. Is cmp() just a
"temporary" solution, or you are going to drop support
for == and friends on strings completely?

"Pavel Minayev" <evilone@omen.ru> wrote in message news:9vrsog$4c1$1@digitaldaemon.com...
> "Walter" <walter@digitalmars.com> wrote in message news:9vrg2r$2q8m$1@digitaldaemon.com...
> > ftp://www.digitalmars.com/dmdalpha3.zip
> >
> > Fixed a lot of bugs regarding arrays and strings.
> >
> > Check out strings.d, the D string runtime library functions. It makes
much
> > use of array slicing and unit tests.
>
> I might be mistaken... but isn't it supposed to be alpha 4
> (since alpha 3 was released several days ago already)? =)

Oh well <g>

"Pavel Minayev" <evilone@omen.ru> wrote in message news:9vs88g$g4j$1@digitaldaemon.com...
> Seems like you've forgot to include the new phobos.lib
> into the archive: it's dated 12/16 and has all the new
> stuff like string functions missing.

Fixed. Oops.

> By the way, a question about strings. Is cmp() just a
> "temporary" solution, or you are going to drop support
> for == and friends on strings completely?

I don't think == is going to work for strings. It is more for detecting if the string references are the same.

"Walter" <walter@digitalmars.com> wrote in message news:9vscf4$jm6$2@digitaldaemon.com...

> "Pavel Minayev" <evilone@omen.ru> wrote in message news:9vs88g$g4j$1@digitaldaemon.com...
> > Seems like you've forgot to include the new phobos.lib
> > into the archive: it's dated 12/16 and has all the new
> > stuff like string functions missing.
>
> Fixed. Oops.
>
> > By the way, a question about strings. Is cmp() just a
> > "temporary" solution, or you are going to drop support
> > for == and friends on strings completely?
>
> I don't think == is going to work for strings. It is more for detecting if the string references are the same.

Not a good idea IMHO. One thing that made me move to C++ from C was better string handling (std::string). I'm not quite sure I'd move from C++ to D if it doesn't have decent string support. Why not just overload comparison operators for char[] anyhow?

"Pavel Minayev" <evilone@omen.ru> wrote in message news:9vsnho$tjq$1@digitaldaemon.com...
> Not a good idea IMHO. One thing that made me move to C++ from
> C was better string handling (std::string). I'm not quite sure
> I'd move from C++ to D if it doesn't have decent string
> support.
> Why not just overload comparison operators for char[]
> anyhow?

Because with == the way it is, I can determine if s[] and t[] share storage.
I have thought about using:
    s.cmp(t)

Walter wrote:
> 
> "Pavel Minayev" <evilone@omen.ru> wrote in message news:9vsnho$tjq$1@digitaldaemon.com...
> > Not a good idea IMHO. One thing that made me move to C++ from
> > C was better string handling (std::string). I'm not quite sure
> > I'd move from C++ to D if it doesn't have decent string
> > support.
> > Why not just overload comparison operators for char[]
> > anyhow?
> 
> Because with == the way it is, I can determine if s[] and t[] share storage.
> I have thought about using:
>     s.cmp(t)

I'm really with Pavel on this one.

I'd guess that it's about 10 times more likely that a programmer will want to know if two strings contain the same sequence of characters than want to know if they share storage. The operator used for the former should be as short, intuitive, and readable as possible.

How about:
   char [] s;
   char [] t;
    ...
   if (s == t)         { ... }   // value equivalence
   if (&s[0] == &t[0]) { ... }   // ref equivalence: literally,
                                 // are the addresses of the first
                                 // chars the same?

I'd like to see this apply to any array type, not just strings.

Alternately, since we have the principle of array operations, with [] referring to the whole array, I could accept:

   if (s == t)     { ... }   // reference equivalence
   if (s[] == t[]) { ... }   // value equivalence

...but that seems dangerously error-prone.

-RB

"Walter" <walter@digitalmars.com> wrote in message news:9vt62e$1em4$1@digitaldaemon.com...

> > Why not just overload comparison operators for char[] anyhow?
>
> Because with == the way it is, I can determine if s[] and t[] share
storage.

If you really need this (and I doubt that it's a frequent operation),
you can always cast pointers:

    char[] s, t;
    if (s == t) ...    // check if strings are equal
    if (cast(void*)s == cast(void*)t)    // check if they share storage

"Russell Borogove" <kaleja@estarcion.com> wrote in message news:3C22286D.A3FCB77C@estarcion.com...

> I'd guess that it's about 10 times more likely that a programmer will want to know if two strings contain the same sequence of characters than want to know if they share storage. The operator used for the former should be as short, intuitive, and readable as possible.

Yes, yes!

> How about:
>    char [] s;
>    char [] t;
>     ...
>    if (s == t)         { ... }   // value equivalence
>    if (&s[0] == &t[0]) { ... }   // ref equivalence: literally,
>                                  // are the addresses of the first
>                                  // chars the same?

An interesting idea.

> I'd like to see this apply to any array type, not just strings.

I don't think it is a good idea to apply it to all arrays, since D states them as "pointers which know size of memory block they point to".

> Alternately, since we have the principle of array operations, with [] referring to the whole array, I could accept:
>
>    if (s == t)     { ... }   // reference equivalence
>    if (s[] == t[]) { ... }   // value equivalence
>
> ...but that seems dangerously error-prone.

I've thought of it as well. AFAIK, D states that for two array slices to be used as operands of one operator, they must be the same size. I don't understand why this should apply to == and other comparison operators - they could just return false if array sizes are different. This way, we'd had full support for string comparisons as well.

On other hand, as you've noticed, it's quite easy to make a mistake, forgetting to put [] at the end...