On Sat, 27 Oct 2012 22:42:21 -0700
Jonathan M Davis <jmdavisProg@gmx.com> wrote:

> On Saturday, October 27, 2012 22:30:25 H. S. Teoh wrote:
> > He who does not appreciate the beauty of language is not worthy to bemoan its flaws.
> 
> That presupposes that the language has any beauty to begin with. It could just be one big flaw. ;)
> 

Did someone say "PHP"? ;)

On Mon, Oct 29, 2012 at 01:28:51AM -0400, Nick Sabalausky wrote:
> On Sat, 27 Oct 2012 22:42:21 -0700
> Jonathan M Davis <jmdavisProg@gmx.com> wrote:
> 
> > On Saturday, October 27, 2012 22:30:25 H. S. Teoh wrote:
> > > He who does not appreciate the beauty of language is not worthy to bemoan its flaws.
> > 
> > That presupposes that the language has any beauty to begin with. It could just be one big flaw. ;)
> > 
> 
> Did someone say "PHP"? ;)

I thought I heard "Javascript"... :-P


T

-- 
In theory, there is no difference between theory and practice.

On Monday, 29 October 2012 at 05:43:43 UTC, H. S. Teoh wrote:
> On Mon, Oct 29, 2012 at 01:28:51AM -0400, Nick Sabalausky wrote:
>> Did someone say "PHP"? ;)
> I thought I heard "Javascript"... :-P

 Both seem to have their own issues, although I'd say javascript is worse than PHP. (at least PHP runs on the server).

On 2012-10-29 07:42, Era Scarecrow wrote:

>   Both seem to have their own issues, although I'd say javascript is
> worse than PHP. (at least PHP runs on the server).

You can run JavaScript on the server too.

-- 
/Jacob Carlborg

On Sunday, 28 October 2012 at 05:28:20 UTC, H. S. Teoh wrote:

> I have to say I was surprised to find out about this after I started
> using D; after first reading TDPL, I had the impression that it was
> supposed to do the "right thing" (and the right thing being == on each
> field, which I assumed the compiler would optimize into a bitwise
> compare where possible).
>
> Let's fix this.
>

There is a problem with floating point memebers, since nan values will always compare false.

There's other things in D that bother me, such as how struc pointers are managed, where they sometimes behave exactly like class references, but not always. The inconsistent behaviour is a trap for the programmer to fall into, and it leads to subtle hard to find errors.

For example:

struct S
{
       int a;
       ~this() {}

}

class C
{
       int a;
       ~this() {}
}

// identical behaviour
auto Sp = new S;
auto Cr = new C;

// identical behaviour
writeln(Sp.a);
writeln(Cr.a);

// identical behaviour
auto Sp2 = Sp;
auto Cr2 = Cr;
writeln(Sp2.a);
writeln(Cr2.a);

// ?
assert(Sp2 == Sp);
assert(Cr2 == Cr);

// different behaviour!
clear(Sp);
clear(Cr);

Last two line compile OK, but clear(Sp) does not invoke the destructor while clear(Cr) does. clear(*Sp) works, but why allow clear(Sp) if it's a pointless operation? Is this a bug in the compiler or with the language design?

Subtle differences like this are very nasty. The code should behave identically for both the struct pointer and the class reference, and if this is not poosible for some obscure reason, then the compiler should fail at the clear(Sp) line.

If I invoke with clear(*Sp) it works, but the inconsistency makes template code that takes in both a struct or a class impossible to do (or at best needlessly difficult to do).

--rt

On Mon, Oct 29, 2012 at 06:34:14PM +0100, Rob T wrote: [...]
> There is a problem with floating point memebers, since nan values will always compare false.

This is IEEE specification. There is no problem.


T

-- 
Frank disagreement binds closer than feigned agreement.

On Monday, 29 October 2012 at 18:39:41 UTC, H. S. Teoh wrote:
> On Mon, Oct 29, 2012 at 06:34:14PM +0100, Rob T wrote:
> [...]
>> There is a problem with floating point memebers, since nan values will
>> always compare false.
>
> This is IEEE specification. There is no problem.
>
>
> T

If struc comparisions compare value by value, and both have Nan values in one member variable, then the two otherwise completely identical structs will always compare false even though they are identical. I think it would be best to have the ability to compare structs in two ways, one as struct equivalence, which would be the default method, the other as vale by value equivalence, which would have to be programmer defined through overload of == operator.

--rt

On Monday, 29 October 2012 at 19:55:41 UTC, Rob T wrote:
> On Monday, 29 October 2012 at 18:39:41 UTC, H. S. Teoh wrote:
>> On Mon, Oct 29, 2012 at 06:34:14PM +0100, Rob T wrote:
>> [...]
>>> There is a problem with floating point memebers, since nan values will
>>> always compare false.
>>
>> This is IEEE specification. There is no problem.
>>
>>
>> T
>
> If struc comparisions compare value by value, and both have Nan values in one member variable, then the two otherwise completely identical structs will always compare false even though they are identical. I think it would be best to have the ability to compare structs in two ways, one as struct equivalence, which would be the default method, the other as vale by value equivalence, which would have to be programmer defined through overload of == operator.
>
> --rt


I understand the problem, but it doesn't seem related to structs at all.

Any two attempts to compare two default-valued floats will fail, irrespective of whether or not they're inside structs.

On Tuesday, 30 October 2012 at 02:27:30 UTC, Mehrdad wrote:
>
> I understand the problem, but it doesn't seem related to structs at all.
>
> Any two attempts to compare two default-valued floats will fail, irrespective of whether or not they're inside structs.

True at the level of float by float comparisons, but not necessarilly true when struct by struct bit pattern compares are done.

My original understandiong of the struct type in D, is that it is defined as a POD which means == (without override) is done as a simple bit pattern compare, rather than doing a value by value compare of member data types. If this is the case, then two structs with default valued equivalent float types should compare equal, even though a value by value compare would compare not equal.

> TDPL clearly states that each of the struct's members are supposed to
> be checked for equality (see section 7.1.5.2, p. 258 - 259).

So I guess that the POD definition of struct was changed at some point?

If so, then how are value by value compares performed when unions are involved? What about when there are member pointers, and other structures that cannot be compared in a meaningful way by default?

I guess the question is if the bit pattern comparision of structs has sufficient justification to be worth having as the default behaviour, or if there is more value attempting a value by value comparision, even though in many situations it may be pointless to attempt either strategy.

In my experience, I cannot recall doing very many direct struct comparisons either as a complete value by value compare or as a full bit pattern compare, I just never found it to be all that useful, no matter, I can try and imagine both strategies being useful in some situations.

With operator overloading you can have both strategies, but only if bit pattern compare is the default stategy, plus with overloading, compare can do exactly what you want to make sense out of unions and pointers, etc. So we should be good as is. I would expect that most times no one compares structs fully by value or by bit pattern anyway, to do so very often is difficult for me to imagine, but I could be wrong.

--rt

On Tuesday, October 30, 2012 08:14:59 Rob T wrote:
> > TDPL clearly states that each of the struct's members are
> > supposed to
> > be checked for equality (see section 7.1.5.2, p. 258 - 259).
> 
> So I guess that the POD definition of struct was changed at some point?

Structs never were just PODs in D. They have _way_ more capabilities to them than that.

If you want bitwise comparison, then use the is operator. That's what it's for.

- Jonathan M Davis