Luna Kid wrote:
>>(Ehhhhh... I mean the null-checking. Anyway, why I wrote
>>that message trivial at all?... Man, I need a sleep again...
> 
>        ^^^^^^^^^^^^^^^
> 
> Nahhh, night good, folks...

You might consider using a newsreader where you can delete your own messages you have already posted, like Mozilla 1.3. Very useful for paranoid androids and lunatic kids, who almost never sleep and first talk then think, like me and you. :>

That would be a boon to many more than you two, methinks. :)

"Ilya Minkov" <midiclub@tiscali.de> wrote in message news:b71sq7$1541$2@digitaldaemon.com...
> Luna Kid wrote:
> >>(Ehhhhh... I mean the null-checking. Anyway, why I wrote that message trivial at all?... Man, I need a sleep again...
> >
> >        ^^^^^^^^^^^^^^^
> >
> > Nahhh, night good, folks...
>
> You might consider using a newsreader where you can delete your own messages you have already posted, like Mozilla 1.3. Very useful for paranoid androids and lunatic kids, who almost never sleep and first talk then think, like me and you. :>
>

What about when doing

    if(x == y)

where either x or y may be null?

"C" <cc.news@gateway.mirlex.com> wrote in message news:b6vmcc$2la9$1@digitaldaemon.com...
> With respect the the issue of accedentially writing
>
> if( wombat == null ) ...
>
> when the intention is
>
> if( wombat === null ) ...
>
> why not always report value comparason with null as
> an error?
>
> id est: `if( wombat == null )` would generate a
> compile time error such as `value comparason (==)
> with null not allowed, did you mean reference
> comparason (===)?`
>
> Such a null value comparason is highly unlikely in
> code - I can think of no circumstances where such a
> comparason would not be an error (can anyone else?).
>
> This should be possible in only a few lines of
> additional code to the compiler, and a line or two
> to the documentation.
>
> [Additionally, declaring `if( wombat == null )` as an
> error would eliminate the need for checking for null
> in the preconditions of the .eq() method.]
>
> C 2003/4/8
>

Matthew Wilson wrote:
> What about when doing
> 
>     if(x == y)
> 
> where either x or y may be null?
> 

Well, that was not the issue I was addressing (I was
thinking more about avoiding typos for x === null),
though I see no reason not to look at that problem too
now you have highlighted it.

I believe the problem here is that we are calling a method
instead of a procedure.  Either using generics (templates)
for operator overloading or using a different calling
convention would be needed to solve this problem.

If however a method is used (as is currently the case) then
we have two possible solutions which improve the situation.

#1: At least the debug version should implicitly add asserts
that x is not null. id est.

	if( x == y ) ...

would be compiled as

	assert( x !== null );	/* implicit assert */
	if( x == y ) ...

The release version could remove such checks - not a perfect
solution, but at least functional.

#2: Otherwise it must be compiled as ...

	if( x === y || ( x !== null && x == y ) ) ...

Assuming eax -> x and ebx -> y this would assemble to ...

	cmp	eax, ebx	; U 1	; x === y
	je	if_block	; V
	test	eax, eax	; U 1	; x !== null
	jnz	if_else_block	; V
	mov	esi, [ebx]	; U 1	; call x == y
	call	[esi+eq_method]	; U *
if_block:
	...
	jmp	if_end_block
if_else_block:
	...
if_end_block:

[Timings are for a Pentium (586) series processor]

The statements including and after the 'mov' command would
be required anyway for the call to the .eq() method - or
may be replaced by inlining said method.

Using this format would take and additional 4 cycles on
a 486, 2 on a pentium and 1 on a P4 (depending on caching).
However, as these tests would be likely to be explicitly
needed within the eq method anyway, the main loss is in
a slight (8-19 byte) increase in programme size for each
== operator.  Also the programme will actually run faster
in the case where x and y are the same object.

This is probably the best solution for D (in my opinion),
as a semantics would do what would be expected. (id est:
if x and y are null evaluate true; if x is null and y is
not null evaluate false; otherwise compare by value.

Further optimisations could be gained by common
subexpression elimination (against the implicit compare)
for explicit constructs such as

	if( wombat !== null && wombat == koala ) ...

The problem with solution #2 is there is a very sutle
gotya in the semantics - id est the .eq() method is not
called when x is null. On the other hand this is better
than the current gotya: a crash.

Thoughts anyone?

C 2003/4/10

C wrote:

> [Additionally, declaring `if( wombat == null )` as an
> error would eliminate the need for checking for null
> in the preconditions of the .eq() method.]

Oops -- no it would not :-(.  Rest of the post is still
valid at least.

C 2003/4/10

Sure. Pretty much tallys with what I've been saying for a couple of weeks. There seem to be less than a handful of objectors, but alas one of them is Walter, and we've not had any comments from him since one that seemed quite final. Alas we may be stuck with this wart (which is pretty much the last one, afaics).

Whether == is a free function, a static member, or an implicit function provided by the compiler doesn't much matter to me, so long as the eq() method always gets given valid this and rhs operands.

Walter, any more persuaded by the growing advocacy?


"C" <cc.news@gateway.mirlex.com> wrote in message news:b74d16$2s9a$1@digitaldaemon.com...
> Matthew Wilson wrote:
> > What about when doing
> >
> >     if(x == y)
> >
> > where either x or y may be null?
> >
>
> Well, that was not the issue I was addressing (I was
> thinking more about avoiding typos for x === null),
> though I see no reason not to look at that problem too
> now you have highlighted it.
>
> I believe the problem here is that we are calling a method instead of a procedure.  Either using generics (templates) for operator overloading or using a different calling convention would be needed to solve this problem.
>
> If however a method is used (as is currently the case) then we have two possible solutions which improve the situation.
>
> #1: At least the debug version should implicitly add asserts that x is not null. id est.
>
> if( x == y ) ...
>
> would be compiled as
>
> assert( x !== null ); /* implicit assert */
> if( x == y ) ...
>
> The release version could remove such checks - not a perfect solution, but at least functional.
>
> #2: Otherwise it must be compiled as ...
>
> if( x === y || ( x !== null && x == y ) ) ...
>
> Assuming eax -> x and ebx -> y this would assemble to ...
>
> cmp eax, ebx ; U 1 ; x === y
> je if_block ; V
> test eax, eax ; U 1 ; x !== null
> jnz if_else_block ; V
> mov esi, [ebx] ; U 1 ; call x == y
> call [esi+eq_method] ; U *
> if_block:
> ...
> jmp if_end_block
> if_else_block:
> ...
> if_end_block:
>
> [Timings are for a Pentium (586) series processor]
>
> The statements including and after the 'mov' command would be required anyway for the call to the .eq() method - or may be replaced by inlining said method.
>
> Using this format would take and additional 4 cycles on
> a 486, 2 on a pentium and 1 on a P4 (depending on caching).
> However, as these tests would be likely to be explicitly
> needed within the eq method anyway, the main loss is in
> a slight (8-19 byte) increase in programme size for each
> == operator.  Also the programme will actually run faster
> in the case where x and y are the same object.
>
> This is probably the best solution for D (in my opinion),
> as a semantics would do what would be expected. (id est:
> if x and y are null evaluate true; if x is null and y is
> not null evaluate false; otherwise compare by value.
>
> Further optimisations could be gained by common subexpression elimination (against the implicit compare) for explicit constructs such as
>
> if( wombat !== null && wombat == koala ) ...
>
> The problem with solution #2 is there is a very sutle
> gotya in the semantics - id est the .eq() method is not
> called when x is null. On the other hand this is better
> than the current gotya: a crash.
>
> Thoughts anyone?
>
> C 2003/4/10
>

"Mike Wynn" <mike.wynn@l8night.co.uk> wrote in message news:b6bpor$22l9$1@digitaldaemon.com...
> I also find the range of float !<> etc operators confusing, not saying
Java,
> C# or C are better with just one test but I have to check what he float/double cmp operators do every time I want to use them.

If you use the C float comparison operators, it works just like C99 says it should. The additional float operators are for the other cases in the truth table, ones that come in real handy when doing carefully constructed float code. Other ways I've seen to do it, like using funky intrinsic functions, are even worse.