View mode: basic / threaded / horizontal-split · Log in · Help
October 29, 2012
Re: Why D is annoying =P
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"? ;)
October 29, 2012
Re: Why D is annoying =P
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.
October 29, 2012
Re: Why D is annoying =P
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).
October 29, 2012
Re: Why D is annoying =P
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
October 29, 2012
Re: Why D is annoying =P
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
October 29, 2012
Re: Why D is annoying =P
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.
October 29, 2012
Re: Why D is annoying =P
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
October 30, 2012
Re: Why D is annoying =P
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.
October 30, 2012
Re: Why D is annoying =P
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
October 30, 2012
Re: Why D is annoying =P
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
4 5 6 7 8 9
Top | Discussion index | About this forum | D home