September 19, 2003 Re: DMD 0.73 release | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter | 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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Julio César Carrascal Urquijo | "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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Sean L. Palmer | "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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jeroen van Bemmel | "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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Sean L. Palmer | 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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter | > 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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jeroen van Bemmel | "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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter | > > 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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Julio César Carrascal Urquijo | "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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter | 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]$
|
Copyright © 1999-2021 by the D Language Foundation