View mode: basic / threaded / horizontal-split · Log in · Help
September 19, 2003
Re: DMD 0.73 release
Walter,

In http://www.digitalmars.com/d/operatoroverloading.html surely the boolean
comparison operators <, >, <= and >= are not commutative?


"Walter" <walter@digitalmars.com> wrote in message
news:bked8d$2pe5$1@digitaldaemon.com...
> Some long awaited features.
>
> http://www.digitalmars.com/d/changelog.html
>
>
>
September 19, 2003
Re: DMD 0.73 release
"Julio César Carrascal Urquijo" <adnoctum@phreaker.net> wrote in message
news:bkfcg0$2275$1@digitaldaemon.com...
> > That's what python does. While it does stand out, it kinda doesn't look
> > right to me, because whenever I see _ _ it looks like some kludgy
internal
> > compiler feature is being accessed.
>
> That's exactly what it is: some (not kludgy but...) internal compiler
> feature.

I disagree that they are some internal compiler feature. They are an
up-front language feature!

> At least would you consider using the "operator/reverse operator"
> keyword as was sugested before? Also name mangling for operators would be
> nice so they don't colide with normal methods when linking.

I am open to a better naming convention. "operator >", for example, does not
work too well because cmp() replaces all the <, <=, >, >= operators.
September 19, 2003
Re: DMD 0.73 release
"Sean L. Palmer" <palmer.sean@verizon.net> wrote in message
news:bkfc91$21qc$1@digitaldaemon.com...
> the names of the overloading aliases should all be made consistent.  If
you
> use opXxxx for the new ones, they should all be opXxxx.

Yes. They'll get changed.

> Overloading ++e and --e
> Since ++e is defined to be semantically equivalent to (e += 1), the
> expression ++e is rewritten as (e += 1), and then checking for operator
> overloading is done. The situation is analogous for --e.
>
> I can tell you that ++e is definitely not semantically equivalent to e +=
1,
> because many things can be incremented but not necessarily by an arbitrary
> integer amount (not to mention += negative number).

In those cases, an assert(i == 1) in the addass(int i) operator should
handle it.

> Excellent work!

Thanks!
September 19, 2003
Re: DMD 0.73 release
"Jeroen van Bemmel" <someone@somewhere.com> wrote in message
news:bkfcts$238q$1@digitaldaemon.com...
> Walter,
>
> In http://www.digitalmars.com/d/operatoroverloading.html surely the
boolean
> comparison operators <, >, <= and >= are not commutative?

Sure they are!
   a < b
and
   b > a
September 19, 2003
Re: DMD 0.73 release
In article <bkfc91$21qc$1@digitaldaemon.com>, Sean L. Palmer says...
>
>Cool beans!  We can now make proper matrix and vector and container classes.
>
>the names of the overloading aliases should all be made consistent.  If you
>use opXxxx for the new ones, they should all be opXxxx.
>
>
>I just noticed this snippet of docs:
>
>Overloading ++e and --e
>Since ++e is defined to be semantically equivalent to (e += 1), the
>expression ++e is rewritten as (e += 1), and then checking for operator
>overloading is done. The situation is analogous for --e.
>

>I can tell you that ++e is definitely not semantically equivalent to e += 1,
>because many things can be incremented but not necessarily by an arbitrary
>integer amount (not to mention += negative number).
>
>To really support this you'd need to define
>
>E add(E lop, int rop)
>{
>    if (rop > 0)
>    {
>        for (int i = rop; --i >= 0; )
>            lop++;
>    }
>}
>
>
>Excellent work!
>
>Sean
>
>"Walter" <walter@digitalmars.com> wrote in message
>news:bked8d$2pe5$1@digitaldaemon.com...
>> Some long awaited features.
>>
>> http://www.digitalmars.com/d/changelog.html
>
>

This again brings to mind what I was thinking about for strings...
I was considering the benefit of overloading the ++ and -- operators for
strings... They could be toUpper() and toLower() operators!!

John Boucher -- Quite contrary
The King had Humpty pushed.
September 19, 2003
Re: DMD 0.73 release
> Sure they are!
>     a < b
> and
>     b > a

No, commutative means "a op b == b op a" where op is the same operator in
both cases. (a<b) != (b<a), so the '<' operator is not commutative, just
like '-' is not
September 19, 2003
Re: DMD 0.73 release
"Jeroen van Bemmel" <someone@somewhere.com> wrote in message
news:bkfmsn$2ubl$1@digitaldaemon.com...
> > Sure they are!
> >     a < b
> > and
> >     b > a
>
> No, commutative means "a op b == b op a" where op is the same operator in
> both cases. (a<b) != (b<a), so the '<' operator is not commutative, just
> like '-' is not

In a mathematical sense you're right, but I just turn < into > to swap the
operands, and >= into <=.
September 20, 2003
Re: DMD 0.73 release
> > That's exactly what it is: some (not kludgy but...) internal compiler
> > feature.
>
> I disagree that they are some internal compiler feature. They are an
> up-front language feature!


Obviously we have diferent opinions :).


> I am open to a better naming convention. "operator >", for example, does
not
> work too well because cmp() replaces all the <, <=, >, >= operators.

They could be the short names that we have right now:

operator cmp()
operaror add()
operator addass()
...

The thing is that they should not collide with regular user-defined methods
(Hence the name mangling). The new "operator" keyword should stand out
suficiently and probably will be easier for syntax highlighting algorithms
than using regular methods with special names.
September 20, 2003
Re: DMD 0.73 release
"Julio César Carrascal Urquijo" <adnoctum@phreaker.net> wrote in message
news:bkgc6t$1rdg$1@digitaldaemon.com...
> They could be the short names that we have right now:
>
> operator cmp()
> operaror add()
> operator addass()
> ...
>
> The thing is that they should not collide with regular user-defined
methods
> (Hence the name mangling). The new "operator" keyword should stand out
> suficiently and probably will be easier for syntax highlighting algorithms
> than using regular methods with special names.

Hmm. I do like that better than __xxx__ !
September 20, 2003
Re: DMD 0.73 release
Walter wrote:
> Some long awaited features.
> 
> http://www.digitalmars.com/d/changelog.html
> 
> 
> 

switch to wchar still has this bug on linux.
/usr/lib/libphobos.a and /etc/dmd.conf updated to those in the 0.73 zip

[mike@localhost tests]$ ~/dmd/bin/dmd
Digital Mars D Compiler v0.73
Copyright (c) 1999-2003 by Digital Mars written by Walter Bright
.....
[mike@localhost tests]$ ~/dmd/bin/dmd -I~/dmd/src/phobos/ wcharswitch.d
gcc wcharswitch.o -o wcharswitch -lphobos -lpthread -lm
[mike@localhost tests]$ ./wcharswitch
switch to default(not afoo or name)
tmp[0..4]:
tmp[0] = 'n'(110)
tmp[1] = 'a'(97)
tmp[2] = 'm'(109)
tmp[3] = 'e'(101)
[mike@localhost tests]$ cat wcharswitch.d
import c.stdio;

wchar[] getName() {
        return "name";
}

int main(char[][] args ) {
        wchar[] tmp = getName(); //getFoo().value;
        switch( tmp ) {
        case "name":
                printf("switch to name\n");
                break;
        case "afoo": printf("switch to afoo\n"); break;
        default:
                printf("switch to default(not afoo or name)\n");
                printf("tmp[0..%d]:\n", tmp.length);
                for( int i = 0; i < tmp.length; i++ ) {
                        printf("tmp[%d] = '%c'(%d)\n", i, 
cast(char)tmp[i], cast(int)tmp[i] );
                }
                break;
        }
        return 0;
}
[mike@localhost tests]$
1 2 3 4 5 6
Top | Discussion index | About this forum | D home