Andy Friesen wrote:

<snip>
> In contrast, a template function is actually *more* optimizable because the comparison function can be inlined instead of requiring a virtual call to a TypeInfo instance. (this virtual call, incidently, itself performs another virtual call: opCmp of the class type)

A builtin could just as well be implemented via a template.  Have you seen my post on this, FTM?

http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/5406

Stewart.

-- 
My e-mail is valid but not my primary mailbox.  Please keep replies on the 'group where everyone may benefit.

Stewart Gordon wrote:

> Andy Friesen wrote:
> 
> <snip>
> 
>> In contrast, a template function is actually *more* optimizable because the comparison function can be inlined instead of requiring a virtual call to a TypeInfo instance. (this virtual call, incidently, itself performs another virtual call: opCmp of the class type)
> 
> 
> A builtin could just as well be implemented via a template.  Have you seen my post on this, FTM?
> 
> http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/5406

No, I must have missed it.  Your proposed solution is more or less perfect. :)

I was working under the assumption that having the compiler instantiate templates would be a nontrivial increase in complexity, so I suggested a solution which can easily be implemented.

 -- andy

Andy Friesen wrote:
<snip>
> I was working under the assumption that having the compiler instantiate templates would be a nontrivial increase in complexity, so I suggested a solution which can easily be implemented.

The compiler instantiates templates whenever the programmer uses them.

It would be fairly trivial to expand

    int[] data;
    ...
    data.sort;

into

    int[] data;
    ...
    internal.sort!(int)(data);

Stewart.

-- 
My e-mail is valid but not my primary mailbox.  Please keep replies on the 'group where everyone may benefit.

Stewart Gordon wrote:
> Andy Friesen wrote:
> <snip>
> 
>> I was working under the assumption that having the compiler instantiate templates would be a nontrivial increase in complexity, so I suggested a solution which can easily be implemented.
> 
> 
> The compiler instantiates templates whenever the programmer uses them.
> 
> It would be fairly trivial to expand
> 
>     int[] data;
>     ...
>     data.sort;
> 
> into
> 
>     int[] data;
>     ...
>     internal.sort!(int)(data);

Right.

I was speaking more from the perspective of how much the compiler would need to be changed to implement this than sheer complexity. (currently, the .sort translation is done in the back-end, where code is assumed to have already been parsed and checked)

 -- andy

"Stewart Gordon" <smjg_1998@yahoo.com> wrote in message news:cf7kdt$hg5$1@digitaldaemon.com...
> Ivan Senji wrote:
>
> <snip>
> > Isn't this identity? x === x ?
> > That is what we have a great seperate operator === and !== for.
> > Why should we also have == be defined by default to do the same as ===.
> > Ridicolous!
> <snip>
>
> We rebutted this argument of yours a while back:
>
> http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/3419
>
> and the chain of followups.  Do you have a further defence of your position here?

There isn't really much more i could say about this. Why does == have to
work as
=== by default? I have never writen a code were two objects are equal
when they are in the same place in memory (===), and when one object is less
than
an other when his adress is smaller. It IMO doesn't make any sence to use
these
comparisons in AAs, as i also wouldn't use these in a contanier.

But it looks like i will have to give up on this for a while :)

>
> Stewart.
>
> --
> My e-mail is valid but not my primary mailbox.  Please keep replies on the 'group where everyone may benefit.

In article <cf8vcm$12k3$1@digitaldaemon.com>,
 "Walter" <newshound@digitalmars.com> wrote:

> "Regan Heath" <regan@netwin.co.nz> wrote in message news:opschjvoak5a2sq9@digitalmars.com...
> > On Mon, 9 Aug 2004 00:32:37 -0700, Walter <newshound@digitalmars.com> wrote:
> > > "Ivan Senji" <ivan.senji@public.srce.hr> wrote in message news:cf3i3d$2a7r$3@digitaldaemon.com...
> > >> What is so special about opCmp, (ok it is used in AAs but couldn't compiler report: "this type cann't be used in AA because of the missing opCmp!")
> > >
> > > Putting it in Object reserves a predictable vtbl[] slot for it.
> >
> > That that achieves... allowing you to aggressively optimise performance?
> >
> > Could you achieve the same thing with some sort of hard-coded globally defined interface? eg.
> >
> > interface IComparable {
> >    int opCmp(IComparable rhs);
> > }
> >
> > class Foo : IComparable {
> > }
> >
> > Does an interface reserve a vtbl slot? and can it be predictable?
> 
> Each interface implemented by a class creates another vptr and corresponding vtbl[] for it. Testing whether an object supports a particular interface is a runtime check, not a compile time one. So, yes, it will impact sorting performance.

So LEAVE the opCmp operator there,  and put assert( 0 ); in it.....

Ivan Senji wrote:
<snip>
> There isn't really much more i could say about this. Why does == have to work as === by default?   I have never writen a code were two
> objects are equal when they are in the same place in memory (===),

To save the user having to write code like

    int opEquals(Object o) {
        return this === o;
    }

everywhere when they _do_ write code like that.

For example, suppose you have an auto class representing a lock on some resource.  How would you define two of them being equal?  Them locking the same resource?  If the setup is such that each resource can only be locked once, then the lock object is equal only to itself.

Suppose you have a GUI library.  Two GUI control objects could be considered equal if they interface the same control.  But if the library can only create controls, and not interface existing controls (such as those on a Windows dialog resource), and cannot create two objects interfacing the same control, then each control object is equal only to itself.

For that matter, I can't think of any examples in which an object should not be equal to itself.  Can you?

> and when one object is less
> than an other when his adress is smaller.

That's changing the subject....

> It IMO doesn't make any sence to use
> these comparisons in AAs, as i also wouldn't use these in a contanier.

Exactly.  That's why it's been suggested plenty of times that Object.opCmp be got rid of, and AAs be reimplemented so that they will work without a comparator.

Stewart.

-- 
My e-mail is valid but not my primary mailbox.  Please keep replies on on the 'group where everyone may benefit.

"Stewart Gordon" <smjg_1998@yahoo.com> wrote in message news:cgamjk$uvl$1@digitaldaemon.com...
> Ivan Senji wrote:
> <snip>
> > There isn't really much more i could say about this. Why does == have to work as === by default?   I have never writen a code were two objects are equal when they are in the same place in memory (===),
>
> To save the user having to write code like
>
>      int opEquals(Object o) {
>          return this === o;
>      }
>
> everywhere when they _do_ write code like that.
>
> For example, suppose you have an auto class representing a lock on some resource.  How would you define two of them being equal?  Them locking the same resource?  If the setup is such that each resource can only be locked once, then the lock object is equal only to itself.
>
> Suppose you have a GUI library.  Two GUI control objects could be considered equal if they interface the same control.  But if the library can only create controls, and not interface existing controls (such as those on a Windows dialog resource), and cannot create two objects interfacing the same control, then each control object is equal only to itself.

OK! These are good examples. But if i was writing that rasource locking stuff and i wanted to know if they lock the same resource i would use === to test if these locks are identical.

> For that matter, I can't think of any examples in which an object should not be equal to itself.  Can you?

Just hypothetically (hm!spelling:) an object whose state depends
on processors clock would never be equal to itself because the two
opEquals could not be called at the same moment. But still
two objects of this type could be identical.

> > and when one object is less
> > than an other when his adress is smaller.
>
> That's changing the subject....

No it isn't:
i see
a==b <-> a===b
and
a<b <-> &a<&b

as part of the same bag of problems. That is one default behavior that i don't like.

> > It IMO doesn't make any sence to use
> > these comparisons in AAs, as i also wouldn't use these in a contanier.
>
> Exactly.  That's why it's been suggested plenty of times that Object.opCmp be got rid of, and AAs be reimplemented so that they will work without a comparator.

Yes! Get rid of them (and take Object.opEquals with it) :)

I still can't understand why it can't work like in C++.
If C++ had AAs it would when seeing int[SomeType] check
if SomeType defines opCmp and opEquals and would report an
error if they are undefined.
And when D looks at int[SomeType] it knows that these exist
(even if we didn't write them, D did). Why?

I don't have anything against AAs needing opCmp and opEquals just as long as we are informed when we havent writen them.

PS.
(a==b) !=== (a===b)
    &&
(a<b) !== (&a<&b)

> Stewart.
>
> --
> My e-mail is valid but not my primary mailbox.  Please keep replies on on the 'group where everyone may benefit.

Ivan Senji wrote:

<snip>
> No it isn't:
> i see
> a==b <-> a===b
> and
> a<b <-> &a<&b
> 
> as part of the same bag of problems.

Yes, the same bag.  But not the same problem.

<snip>
> I don't have anything against AAs needing opCmp and opEquals
> just as long as we are informed when we havent writen them.
<snip>

But what should it mean if opEquals hasn't been written?

(a) that it's a class representing a one-to-one lock or GUI widget or something, in which an object is equal only to itself and the type could be used as an AA key?  Makes sense to me.
(b) that an object shouldn't even be equal to itself, preventing use in AAs?
(c) that the class isn't finished?

Stewart.

-- 
My e-mail is valid but not my primary mailbox.  Please keep replies on on the 'group where everyone may benefit.

Stewart Gordon wrote:

> For that matter, I can't think of any examples in which an object should not be equal to itself.  Can you?

NaN? :)

The real problem is that opEquals and opCmp are defined for Object, which means that any object must be comparable to any other:

    class Apple { }
    class Orange { }

    Apple a = new Apple();
    Orange o = new Orange();

    bool b = a == o;

 -- andy