On Tue, 20 Aug 2002 11:33:34 -0700 "Walter" <walter@digitalmars.com> wrote:

> Correct. But if you overload it, you can change the return type - but be aware that will create more than one entry for cmp in the vtbl[].

Then, take a look at this:

	class Foo
	{
		float cmp() { ... }
	}

	void process(Object a, Object b)
	{
		if (a < b)
			...
		else
			...
	}

	int main()
	{
		process(new Foo, new Foo);
	}

Now, which version of cmp() will be used in process()?

"Joe Battelle" <Joe_member@pathlink.com> wrote in message news:aju8ag$1s8n$1@digitaldaemon.com...
> >Correct. But if you overload it, you can change the return type - but be aware that will create more than one entry for cmp in the vtbl[].
> Um, I think overload is too strong a word for this.  "Fudge" might be more accurate <g>.  It might be good if you could overload based on just the
return
> type--but you can't in the current implementation.

What you'd have to do for cmp is provide two functions:

class MyFloat {
    int cmp(Object o);
    float cmp(MyFloat f);
}

The
    int Foo.cmp(Object o);
version will be used. Since process() doesn't know about NaN's anyway,
you'll need to overload int cmp(Object o); to perhaps throw an exception on
a NaN, and then write a float cmp(MyFloat o) to handle NaN's.

"Pavel Minayev" <evilone@omen.ru> wrote in message
news:CFN374890162473958@news.digitalmars.com...
On Tue, 20 Aug 2002 11:33:34 -0700 "Walter" <walter@digitalmars.com> wrote:

> Correct. But if you overload it, you can change the return type - but be aware that will create more than one entry for cmp in the vtbl[].

Then, take a look at this:

class Foo
{
float cmp() { ... }
}

void process(Object a, Object b)
{
if (a < b)
...
else
...
}

int main()
{
process(new Foo, new Foo);
}

Now, which version of cmp() will be used in process()?

Walter wrote:

> "Burton Radons" <loth@users.sourceforge.net> wrote in message
> news:3D5F0476.1060203@users.sourceforge.net...
> 
>>Walter, could you back one of us up here, please?
>>
> 
> I think it will work right if:
>     a op b
> is rewritten as:
>     a.cmp(b) op 0
> For the nan cases, the cmp function can return nan's.

I don't have a problem with making this change, but I think it should be consistent or it'll cause more confusion than enlightenment.  Always returning float from cmp is actually helpful, since it can then be used if eq isn't provided, which it almost universally won't be, and it handles "long - long" properly.  Better yet would be to remove eq and see how many complaints there are.

On Thu, 08 Aug 2002 06:57:04 -0700, Burton Radons <loth@users.sourceforge.net> wrote:

>I've accidentally implemented operator overloading in my port.  It was kind of incidental to other work, so I thought "what the hell" and threw it in.  But this brings up the whole issue of syntax, and I think that should be voted on to specify the syntax on my side and to influence Walter when he decides to do this topic.

I'm scared of voting... it's too much like a committee...

On Wed, 21 Aug 2002 01:21:43 -0700 "Walter" <walter@digitalmars.com> wrote:

> The
>     int Foo.cmp(Object o);
> version will be used. Since process() doesn't know about NaN's anyway,
> you'll need to overload int cmp(Object o); to perhaps throw an exception on
> a NaN, and then write a float cmp(MyFloat o) to handle NaN's.

process() doesn't need to know anything of NaNs - but it relies on the fact that correct comparison is performed regardless of actual types of objects.

Maybe it would really be better to make cmp() always return float? I don't think it would add any significant slowdown, but the feature would then be consistent...

Hi,

"Pavel Minayev" <evilone@omen.ru> wrote in message news:CFN374899500592593@news.digitalmars.com...
> Maybe it would really be better to make cmp() always return float? I don't think it would add any significant slowdown, but the feature would then be consistent...

If floating point isn't supported by hardware, it would cause a major performance hit.

Regards,
Martin M. Pedersen

On Wed, 21 Aug 2002 22:11:45 +0100 "Martin M. Pedersen" <mmp@www.moeller-pedersen.dk> wrote:

> If floating point isn't supported by hardware, it would cause a major performance hit.

Then, let's define a standard "fp-comparison" interface in object.d:

	interface CompareFP
	{
		float cmp();
	}

Now process() would be:

	process(CompareFP a, CompareFP b)
	{
		...
	}

And all problems are gone.

"Burton Radons" <loth@users.sourceforge.net> wrote in message news:3D63BB45.3040706@users.sourceforge.net...
> I don't have a problem with making this change, but I think it should be consistent or it'll cause more confusion than enlightenment.  Always returning float from cmp is actually helpful, since it can then be used if eq isn't provided, which it almost universally won't be, and it handles "long - long" properly.  Better yet would be to remove eq and see how many complaints there are.

Always returning float has a problem for embedded systems which may want to use an integer-only subset of D, and also it would be a problem in general for machines which have arbitrarilly slow floating point.

The reason for a separate eq from cmp is that for many objects there is no concept of "less than", although there is a concept for "equals".

"Toyotomi" <io219@attbi.com> wrote in message news:oll7mu4nat45gi1gjfvslh7mriv0b3jer7@4ax.com...
> I'm scared of voting... it's too much like a committee...

I think democratically designed languages tend to be failures <g>. Nevertheless, ignoring feedback from users is equally perilous. These kinds of discussions help me to understand what things are important and what are not.