"Barry Pederson" <barryp@yahoo.com> wrote in message news:3C883E19.3030407@yahoo.com...
> The D HTML page on arrays mentions:
>
> -----------
>   Strings can be copied, compared, concatenated, and appended:
>
>     if (str1 < str3) ...
> -----------
>
> When I see "compared", I would take that to mean you could compare for
content
> equality using the "==" operator - but that doesn't seem to be the case,
and D
> seems to just do C-style pointer comparisons.
>
> Is string-content comparison using == just something that hasn't been implemented yet?  or are the docs a bit misleading and string.cmp() is how it's going to have to be done?
>
> Barry
>

Sorry about the multiple posts. Bloody Outlook Express just took over!

"Barry Pederson" <barryp@yahoo.com> wrote in message news:3C883E19.3030407@yahoo.com...
> The D HTML page on arrays mentions:
>
> -----------
>   Strings can be copied, compared, concatenated, and appended:
>
>     if (str1 < str3) ...
> -----------
>
> When I see "compared", I would take that to mean you could compare for
content
> equality using the "==" operator - but that doesn't seem to be the case,
and D
> seems to just do C-style pointer comparisons.
>
> Is string-content comparison using == just something that hasn't been implemented yet?  or are the docs a bit misleading and string.cmp() is how it's going to have to be done?
>
> Barry
>

What is that coders are trying find out when they code :

     if (a == b)

My guess is that, of all the properties of 'a' and 'b', they are trying to find out if the value (aka content) of 'a' is identical to the value  of 'b'.

Now you and I know that 'a' and 'b' are really a type of shorthand for referencing a RAM location, and depending on the data type, how much RAM they take up. But programming languages exist to hide all that yucky detail. So therefore, when we see 'a' and 'b' in source code, we tend to think of them as having content or value.

If D wants to be self consistent, plus being helpful to coders, this comparision should mean the same regardless of the datatypes that 'a' and 'b' happen to be.

For example, if 'a' and 'b' were both integers, we would expect to be comparing the contents of 'a' and 'b', not their RAM addresses.

Also, if 'a' and 'b' were both floating point numbers, we would expect to be comparing the contents of 'a' and 'b', not their RAM addresses.

Now if 'a' and 'b' are arrays, shouldn't we also expect D to compare their contents rather than the RAM addresses of their first byte?

N.B.: Disregard this idea if D is trying to be (C++)++

Derjo Phar wrote:

> What is that coders are trying find out when they code :
> 
>      if (a == b)
> 
> My guess is that, of all the properties of 'a' and 'b', they are trying to
> find out if the value (aka content) of 'a' is identical to the value  of
> 'b'.
> 
> Now you and I know that 'a' and 'b' are really a type of shorthand for
> referencing a RAM location, and depending on the data type, how much RAM
> they take up. But programming languages exist to hide all that yucky detail.
> So therefore, when we see 'a' and 'b' in source code, we tend to think of
> them as having content or value.
> 
> If D wants to be self consistent, plus being helpful to coders, this
> comparision should mean the same regardless of the datatypes that 'a' and
> 'b' happen to be.
> 
> For example, if 'a' and 'b' were both integers, we would expect to be
> comparing the contents of 'a' and 'b', not their RAM addresses.
> 
> Also, if 'a' and 'b' were both floating point numbers, we would expect to be
> comparing the contents of 'a' and 'b', not their RAM addresses.
> 
> Now if 'a' and 'b' are arrays, shouldn't we also expect D to compare their
> contents rather than the RAM addresses of their first byte?

Well said.

Let me throw this out:  arrays have a length and a pointer.  We can access the length with the .length property, how about adding a .pointer (or .ptr, or .addr) property to access the pointer to the array's data (that would the appropriate type for the array).   So for example, given "ubyte[] b", b.pointer would have the type: (ubyte *)

Then if you wanted to do a comparison of the RAM addresses of two arrays, you could say:

    if (a.pointer == b.pointer)
        ...

Instead of the more verbose:

    if ((ubyte *) a == (ubyte *) b)
        ...

There's also the advantage that if you ever changed the array types for a or b, you wouldn't have to go through and change the casts in any pointer comparisons.

Then you'd be free to use "==" for array content comparison.  Right now there is string.cmp() for char[] comparison, but what about comparing other array types?

Ideally, you should even be able to compare arrays of different types, assuming the elements within the arrays can be compared.  So [1, 2, 3] == [1.0, 2.0, 3.0].

	Barry

"Derjo Phar" <not@available.com> wrote in message news:a6budn$1h6n$1@digitaldaemon.com...

> Now if 'a' and 'b' are arrays, shouldn't we also expect D to compare their contents rather than the RAM addresses of their first byte?

I believe this is wrong approach. Dynamic arrays are just pointers which know size of the data they point to.

Pavel Minayev wrote:
> "Derjo Phar" <not@available.com> wrote in message
> news:a6budn$1h6n$1@digitaldaemon.com...
> 
> 
>>Now if 'a' and 'b' are arrays, shouldn't we also expect D to compare their
>>contents rather than the RAM addresses of their first byte?
>>
> 
> I believe this is wrong approach. Dynamic arrays are just pointers
> which know size of the data they point to.

The argument still applies. I rarely care what the
addresses of arrays are; I frequently care what the
contents are.

The only exception I can see is when you're trying to
see if a and b are in fact the exact same array. I'm
not sure how often this will come up in D.

If I remember rightly that two array slices can
share storage, then the (e.g.) [0..3] and the [0..6]
slice of a given array could return equality in
comparison because they have the same base address.
Is that useful to anyone?

-RB

"Pavel Minayev" <evilone@omen.ru> wrote in message news:a6cch7$1mph$1@digitaldaemon.com...
> "Derjo Phar" <not@available.com> wrote in message news:a6budn$1h6n$1@digitaldaemon.com...
>
> > Now if 'a' and 'b' are arrays, shouldn't we also expect D to compare
their
> > contents rather than the RAM addresses of their first byte?
>
> I believe this is wrong approach.

Why?

> Dynamic arrays are just pointers which know size of the data they point to.

Doesn't that depend entirely on the implementation? Or are you saying that it is axiomatic that dynamic array's are a type of pointer?

I thought that a dynamic array is a data structure that can contain zero or more items of data, in which each item can be uniquely referenced by an index value.  And that doesn't sound like a pointer to me.

But in any case, I would hope we are not talking about generated machine code (implementation details), which is used by computers, but about program source code, which is used by people.

So when we come back to people coding, what is the more common requirement we have? To see if two variables are referencing the same array, or to see if two variables contain the same data?

From my experience so far (I started programming in 1972), I believe that it content comparision is intended far more frequently that pointer comparision.

If D were to adopt something like the ".pointer" property syntax (thank you Barry) for all variables, it would have a few side-effects that would be beneficial. The first being that the intentions of coders would be more explicitly expressed in the source code. Another would be that changing the datatype of a variable would not be the large exercise in code changing it is today with C.

"Derjo Phar" <not@available.com> wrote in message news:a6du8i$2g5t$1@digitaldaemon.com...

> Doesn't that depend entirely on the implementation? Or are you saying that it is axiomatic that dynamic array's are a type of pointer?

I'm not sure. Walter might tell. =)

> I thought that a dynamic array is a data structure that can contain zero
or
> more items of data, in which each item can be uniquely referenced by an index value.  And that doesn't sound like a pointer to me.

Well actually it's a _pointer_ to the "data structure that ...". This comes from the fact that you can have two overlapping D arrays:

    int[] foo, bar;
    foo = bar;    // now they share the same memory block

> So when we come back to people coding, what is the more common requirement we have? To see if two variables are referencing the same array, or to see if two variables contain the same data?
>
> From my experience so far (I started programming in 1972), I believe that
it
> content comparision is intended far more frequently that pointer comparision.

In general, I agree. D arrays are somewhat low-level, and making them more high-level seems like a logical step for me. It would be really nice to have "=" copy the arrays, and "==" to compare them for equality. This would also solve most (if not all) of string problems.

That .pointer idea is also great.

"Pavel Minayev" <evilone@omen.ru> wrote in message news:a6e005$2gpd$1@digitaldaemon.com...
> "Derjo Phar" <not@available.com> wrote in message news:a6du8i$2g5t$1@digitaldaemon.com...
<SNIP>
> > So when we come back to people coding, what is the more common
requirement
> > we have? To see if two variables are referencing the same array, or to
see
> > if two variables contain the same data?
> >
> > From my experience so far (I started programming in 1972), I believe
that
> it
> > content comparision is intended far more frequently that pointer comparision.
>
> In general, I agree. D arrays are somewhat low-level, and making them more high-level seems like a logical step for me. It would be really nice to have "=" copy the arrays, and "==" to compare them for equality. This would also solve most (if not all) of string problems.
>
> That .pointer idea is also great.
>



I was talking about this in the discussion "Operator overloading: A way to make everybody happy?": <a68s84$872$1@digitaldaemon.com>

Basically, normally reference semantics is what you need in most
cases. Java and Delphi recognized this and made all class
variables references. C++ uses value semantics as the standard
case, and you have to use pointers to avoid it. A lot of
programmers hate it, but it offers some significant advantages
when using operator overloading.
My reasoning is that you use operator overloading because you
are using a class to simulate some 'basic' type that does not exist,
such as a string, an int256 or a date.

Now when you see the following declarations:

date dtA = new date (19, 12, 1976);
date dtB = new date (19, 12, 1976);
string sA = new String ('Hello World!');
string sB = new String ('Hello World!');
int256 iA = new int256 (12);
int256 iB = new int256 (12);

What would you expect the following expressions to eveluate to?

if (dtA == dtB)
if (sA == sB)
if (iA == iB)

You might be surprised to learn that with reference semantics these expressions would in fact all evaluate to false, simply because references A and B do not reference the same objects! With value semantics you would get the "correct" result of true, because the value of the variables is the same in all the cases. Basic variables such as int use value semantics, so that is what we need to make operator overloading work in a logical manner on classes.

So how about a way to say "use value semantics" or "use reference semantics"?

Maybe this:

if (&dtA == &dtB)  // Compare references
if (*dtA == *dtB)    // Compare values

Comments, suggestions, negatives?


--
Stijn
OddesE_XYZ@hotmail.com
http://OddesE.cjb.net
__________________________________________
Remove _XYZ from my address when replying by mail

"OddesE" <OddesE_XYZ@hotmail.com> wrote in message news:a6j4im$1kgt$1@digitaldaemon.com...

> So how about a way to say "use value semantics" or "use reference semantics"?
>
> Maybe this:
>
> if (&dtA == &dtB)  // Compare references
> if (*dtA == *dtB)    // Compare values
>
> Comments, suggestions, negatives?

First of all, where's (dtA == dtB)?

Then, &foo is a pointer to foo. So:

    char[] foo;
    char[]* bar = &foo;

I guess that, for objects, you'd prefer reference semantics
(you can always use .cmp() to check for equality). For arrays,
however, value semantics seems to be preferrable.