www.digitalmars.com         C & C++   DMDScript  

D - DMD 0.73 release

reply "Walter" <walter digitalmars.com> writes:
Some long awaited features.

http://www.digitalmars.com/d/changelog.html
Sep 19 2003
next sibling parent "Matthew Wilson" <matthew stlsoft.org> writes:
Walter, you ROCK!

"Walter" <walter digitalmars.com> wrote in message
news:bked8d$2pe5$1 digitaldaemon.com...
 Some long awaited features.

 http://www.digitalmars.com/d/changelog.html

Sep 19 2003
prev sibling next sibling parent "Riccardo De Agostini" <riccardo.de.agostini email.it> writes:
You're my hero! :)

"Walter" <walter digitalmars.com> ha scritto nel messaggio
news:bked8d$2pe5$1 digitaldaemon.com...
 Some long awaited features.

 http://www.digitalmars.com/d/changelog.html

Sep 19 2003
prev sibling next sibling parent reply "Matthew Wilson" <matthew stlsoft.org> writes:
Love your work, but have a gripe and a request.

Gripe: names of special methods as opIndex, opSlice etc are neither
sufficiently unambiguous, or sufficiently eye-catching. Can you explain why
you are not moved by something like __index__, __slice__ or such?

Request: The index operator is documented as taking an int. Can it also
take, say, a char[]? If so, you should put that in the doc. If not, consider
this a request for that?


"Walter" <walter digitalmars.com> wrote in message
news:bked8d$2pe5$1 digitaldaemon.com...
 Some long awaited features.

 http://www.digitalmars.com/d/changelog.html

Sep 19 2003
next sibling parent reply "Walter" <walter digitalmars.com> writes:
"Matthew Wilson" <matthew stlsoft.org> wrote in message
news:bkf0c3$145b$1 digitaldaemon.com...
 Love your work, but have a gripe and a request.

 Gripe: names of special methods as opIndex, opSlice etc are neither
 sufficiently unambiguous, or sufficiently eye-catching.

I put them in boldface in the documentation <g>.
 Can you explain why
 you are not moved by something like __index__, __slice__ or such?

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.
 Request: The index operator is documented as taking an int. Can it also
 take, say, a char[]? If so, you should put that in the doc. If not,

 this a request for that?

It can take any type - the usual overloading rules apply. The documentation just gives an example where it uses an int. There can be multiple property setters, and setters can have a return value.
Sep 19 2003
parent reply "Julio CÚsar Carrascal Urquijo" <adnoctum phreaker.net> writes:
 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. 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.
 Request: The index operator is documented as taking an int. Can it also
 take, say, a char[]? If so, you should put that in the doc. If not,

 this a request for that?

It can take any type - the usual overloading rules apply. The

 just gives an example where it uses an int. There can be multiple property
 setters, and setters can have a return value.

Nice :).
Sep 19 2003
parent reply "Walter" <walter digitalmars.com> writes:
"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


 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.
Sep 19 2003
parent reply "Julio CÚsar Carrascal Urquijo" <adnoctum phreaker.net> writes:
 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

 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.
Sep 19 2003
parent reply "Walter" <walter digitalmars.com> writes:
"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

 (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__ !
Sep 19 2003
parent reply "Matthew Wilson" <matthew stlsoft.org> writes:
I'm equally happy with __add__ and operator add(). Just not opAdd

In fact I think I like operator add() more.

However, it begs the question why we just don't have operator +() ?

"Walter" <walter digitalmars.com> wrote in message
news:bkgdgr$1vnq$1 digitaldaemon.com...
 "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

 (Hence the name mangling). The new "operator" keyword should stand out
 suficiently and probably will be easier for syntax highlighting


 than using regular methods with special names.

Hmm. I do like that better than __xxx__ !

Sep 19 2003
next sibling parent reply "Matthew Wilson" <matthew stlsoft.org> writes:
Also, all this merry nomenclatural banter masks the deeper issue of concern
that operators are member functions. :(


"Matthew Wilson" <matthew stlsoft.org> wrote in message
news:bkgh89$2d4f$1 digitaldaemon.com...
 I'm equally happy with __add__ and operator add(). Just not opAdd

 In fact I think I like operator add() more.

 However, it begs the question why we just don't have operator +() ?

 "Walter" <walter digitalmars.com> wrote in message
 news:bkgdgr$1vnq$1 digitaldaemon.com...
 "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

 (Hence the name mangling). The new "operator" keyword should stand out
 suficiently and probably will be easier for syntax highlighting


 than using regular methods with special names.

Hmm. I do like that better than __xxx__ !


Sep 19 2003
next sibling parent reply "Sean L. Palmer" <palmer.sean verizon.net> writes:
Hear!

In many cases it is not possible to determine which of two classes should
have the operator.

What if two different classes both overload operators on the other class?
Is that a conflict?

class A { operator_cmp(B b) { return -b.cmp(this); } }
class B { operator_cmp(A a) { return -a.cmp(this); } }

It would be best if you just put it in the global namespace

operator A a cmp B b noncommutative
{
    return a.member < b.member ? -1 : a.member == b.member ? 0 : 1;
}

Sean

"Matthew Wilson" <matthew stlsoft.org> wrote in message
news:bkghmm$2eu1$1 digitaldaemon.com...
 Also, all this merry nomenclatural banter masks the deeper issue of

 that operators are member functions. :(

Sep 19 2003
parent reply "Matthew Wilson" <matthew stlsoft.org> writes:
Koenig lookup next stop. He he

I understand why language writers (C# & D, at least) have favoured having
them defined as class members, but it's simply wrong.

Having said that, I can probably live with them as such, if only they were
static.

Don't get me wrong: you're completely right about it. I'm just being a
pragmatist as usual.


"Sean L. Palmer" <palmer.sean verizon.net> wrote in message
news:bkgl1k$2rbe$1 digitaldaemon.com...
 Hear!

 In many cases it is not possible to determine which of two classes should
 have the operator.

 What if two different classes both overload operators on the other class?
 Is that a conflict?

 class A { operator_cmp(B b) { return -b.cmp(this); } }
 class B { operator_cmp(A a) { return -a.cmp(this); } }

 It would be best if you just put it in the global namespace

 operator A a cmp B b noncommutative
 {
     return a.member < b.member ? -1 : a.member == b.member ? 0 : 1;
 }

 Sean

 "Matthew Wilson" <matthew stlsoft.org> wrote in message
 news:bkghmm$2eu1$1 digitaldaemon.com...
 Also, all this merry nomenclatural banter masks the deeper issue of

 that operators are member functions. :(


Sep 19 2003
parent reply "Sean L. Palmer" <palmer.sean verizon.net> writes:
"Matthew Wilson" <matthew stlsoft.org> wrote in message
news:bkgldj$2slf$1 digitaldaemon.com...
 Koenig lookup next stop. He he

You're funny!! ;)
 I understand why language writers (C# & D, at least) have favoured having
 them defined as class members, but it's simply wrong.

yes
 Having said that, I can probably live with them as such, if only they were
 static.

I don't understand.
 Don't get me wrong: you're completely right about it. I'm just being a
 pragmatist as usual.

Don't worry about it. Sean
 "Sean L. Palmer" <palmer.sean verizon.net> wrote in message
 news:bkgl1k$2rbe$1 digitaldaemon.com...
 Hear!

 In many cases it is not possible to determine which of two classes


 have the operator.

 What if two different classes both overload operators on the other


 Is that a conflict?

 class A { operator_cmp(B b) { return -b.cmp(this); } }
 class B { operator_cmp(A a) { return -a.cmp(this); } }

 It would be best if you just put it in the global namespace

 operator A a cmp B b noncommutative
 {
     return a.member < b.member ? -1 : a.member == b.member ? 0 : 1;
 }

 Sean

 "Matthew Wilson" <matthew stlsoft.org> wrote in message
 news:bkghmm$2eu1$1 digitaldaemon.com...
 Also, all this merry nomenclatural banter masks the deeper issue of

 that operators are member functions. :(



Sep 19 2003
parent reply "Matthew Wilson" <matthew stlsoft.org> writes:
 Having said that, I can probably live with them as such, if only they


 static.

I don't understand.

Even though your assertion that they should be in the global namespace is correct I, as a pragmatic fellow, will be content (at least to the point of ceasing my whingeing) if they are implement as *static* member functions. I can't live with the status quo, of them as non-static member functions, and I don't plan to stop campaigning against them (see this month's CUJ!)
Sep 19 2003
parent reply "Sean L. Palmer" <palmer.sean verizon.net> writes:
"Matthew Wilson" <matthew stlsoft.org> wrote in message
news:bkgn1s$30ng$1 digitaldaemon.com...
 Having said that, I can probably live with them as such, if only they


 static.

I don't understand.

Even though your assertion that they should be in the global namespace is correct I, as a pragmatic fellow, will be content (at least to the point

 ceasing my whingeing) if they are implement as *static* member functions.

 can't live with the status quo, of them as non-static member functions,

 I don't plan to stop campaigning against them (see this month's CUJ!)

Ok, I still don't understand how you would want them declared. If static, they don't automatically take any arguments, and what you get is essentially the same thing as a global function, only it's somehow hidden in the class namespace? How would you use it then? It wouldn't resolve the issue of which class should it be a static member function of! And you'd still need "friend" capability, though not for both classes, just for one of them. Sean
Sep 20 2003
parent Mike Wynn <mike l8night.co.uk> writes:
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Sean L. Palmer wrote:
 "Matthew Wilson" <matthew stlsoft.org> wrote in message
 news:bkgn1s$30ng$1 digitaldaemon.com...
 
Having said that, I can probably live with them as such, if only they


were
static.

I don't understand.

Even though your assertion that they should be in the global namespace is correct I, as a pragmatic fellow, will be content (at least to the point

of
ceasing my whingeing) if they are implement as *static* member functions.

I
can't live with the status quo, of them as non-static member functions,

and
I don't plan to stop campaigning against them (see this month's CUJ!)

Ok, I still don't understand how you would want them declared. If static, they don't automatically take any arguments, and what you get is essentially the same thing as a global function, only it's somehow hidden in the class namespace? How would you use it then? It wouldn't resolve the issue of which class should it be a static member function of! And you'd still need "friend" capability, though not for both classes, just for one of them. Sean

operators should be in the form binary/op= : RT operator ( LHS, RHS ) { .... } where ever declared should be a "friend" or the types RT, LHS, RHS unary/++ : RT operator ( T ) { .... } where ever declared should be a "friend" or the types RT, T e.g. int operator_add( A a, B b ) { ... } A operator_add( A a, B b ) { ... } B operator_add( A a, B b ) { ... } class A {}; class B : A {} A b, a; int i; b = new B(); a = new A(); i = a+b; // should call int operator_add( A, B ); b = a+b; // should call B operator_add( A, B ); a more complex example say `i = a+b+b`; is i = ((a + b) + b); the first (a + b) would be expected to be evaluated in the same context as the RHS unless cast so would be B t1 = a+b; B op_add( A, B) i = t1 + b; int op_add( B, B ); to force the first a+b to be evaluated in A context it would have to be rewritten as i = (cast(A)(a + b) + b); would now become A t1 = a+b; A op_add( A, B ) i = t1 + b; int op_add( A, B ); I've attached some example code I've been playing with to try to get this behaviour from D classes, but currently am stummped on how to get the operators to "evaluate" into context (so far my chose is lazy eval ) i = a+b would be written i = (a+b).eval(int.classinfo); (all operators return "LazyEvaluators") so a+b+b => (a+b) =>LazyEval["+" : A, B => Unknown] + B => LazyEval( "+" : LazyEval, B => Unknown ) eval( int.classinfo) would then process A,B=>B; B+B=>int throwing runtime exceptions along the way if operators where missing. I also do not believe in r_sub; instead B operator_sub( B, A ); and B operator_sub( A, B ); should be written (if required)
Sep 20 2003
prev sibling parent "Julio CÚsar Carrascal Urquijo" <adnoctum phreaker.net> writes:
 However, it begs the question why we just don't have operator +() ?

Because of the issue that Walter just bring up: operator <() operator =() operator >() are really implemented by operator cmp()
 Also, all this merry nomenclatural banter masks the deeper issue of

 that operators are member functions. :(

That's why I'm asking for name mangling, so we can have: "operator add()" and "void add()" in the same class (Not sure for what will we need it, though)
Sep 19 2003
prev sibling parent "Sean L. Palmer" <palmer.sean verizon.net> writes:
If you want to have it be easier to parse, require an underscore between
them.  Or whatever the preferred language multi-word-naming style is.
InitialCaps?

operator_cmp()
operator_add()

Sean

"Matthew Wilson" <matthew stlsoft.org> wrote in message
news:bkgh89$2d4f$1 digitaldaemon.com...
 I'm equally happy with __add__ and operator add(). Just not opAdd

 In fact I think I like operator add() more.

 However, it begs the question why we just don't have operator +() ?

 "Walter" <walter digitalmars.com> wrote in message
 news:bkgdgr$1vnq$1 digitaldaemon.com...
 "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

 (Hence the name mangling). The new "operator" keyword should stand out
 suficiently and probably will be easier for syntax highlighting


 than using regular methods with special names.

Hmm. I do like that better than __xxx__ !


Sep 19 2003
prev sibling parent "Sean L. Palmer" <palmer.sean verizon.net> writes:
Why not __op__op__op__op__index___________ ?

Is that sufficiently eye-catching for you?  What do you think adding these
underscores is helping?  It's just going to confuse these operators with
everything else that is supposed to stand out visually and someone decides
to add underscores to.  It's not like they're keywords.

It's really just requesting that everybody have to type more.

Sean

"Matthew Wilson" <matthew stlsoft.org> wrote in message
news:bkf0c3$145b$1 digitaldaemon.com...
 Love your work, but have a gripe and a request.

 Gripe: names of special methods as opIndex, opSlice etc are neither
 sufficiently unambiguous, or sufficiently eye-catching. Can you explain

 you are not moved by something like __index__, __slice__ or such?

Sep 19 2003
prev sibling next sibling parent reply Andy Friesen <andy ikagames.com> writes:
Walter wrote:
 Some long awaited features.
 
 http://www.digitalmars.com/d/changelog.html

woohoo! I'm a bit worried about the interface for defining properties. The way it is, you could do weird things like document.save="filename"; whether or not it was intended to be used that way. Is an opIndex overload to handle slice assignment out of the question? opIndex(start, end, newValue) or somesuch. Also a tiny note: the opCall and opIndex examples don't use new to allocate an object. (this has tripped people up in the past, if I recall) -- andy
Sep 19 2003
parent reply "Walter" <walter digitalmars.com> writes:
"Andy Friesen" <andy ikagames.com> wrote in message
news:bkf0qv$15vh$1 digitaldaemon.com...
 Walter wrote:
 Some long awaited features.

 http://www.digitalmars.com/d/changelog.html

woohoo! I'm a bit worried about the interface for defining properties. The way it is, you could do weird things like document.save="filename"; whether or not it was intended to be used that way.

Yes, you can do that. Whether you want to or not is a style issue.
 Is an opIndex overload to handle slice assignment out of the question?
 opIndex(start, end, newValue) or somesuch.

I'm a little unsure about that.
 Also a tiny note: the opCall and opIndex examples don't use new to
 allocate an object. (this has tripped people up in the past, if I recall)

That's because they are structs and don't need it (!). I used both struct and class examples just to show that operator overloading works with each.
Sep 19 2003
parent reply "Philippe Mori" <philippe_mori hotmail.com> writes:
 I'm a bit worried about the interface for defining properties.  The way
 it is, you could do weird things like document.save="filename"; whether
 or not it was intended to be used that way.

Yes, you can do that. Whether you want to or not is a style issue.

I would prefer that properties attributes would be required in the declaration to allows the uses of a function as a property. Otherwise, this could lead to code obfuscation... Function call syntax make the code more clear that an action will occurs. Also, if properties are explicitly documented as such, this would be usefull when D will be used for COM or .NET programming or for visual editing of an UI (the inspector will display public (or published) methods (as in Delphi) but not arbitrary method that happen to have the proper number of argument (0 or 1). Also having a keyword would allows support for array properties.
Sep 20 2003
parent reply Mike Wynn <mike l8night.co.uk> writes:
Philippe Mori wrote:
I'm a bit worried about the interface for defining properties.  The way
it is, you could do weird things like document.save="filename"; whether
or not it was intended to be used that way.

Yes, you can do that. Whether you want to or not is a style issue.

I would prefer that properties attributes would be required in the declaration to allows the uses of a function as a property. Otherwise, this could lead to code obfuscation... Function call syntax make the code more clear that an action will occurs. Also, if properties are explicitly documented as such, this would be usefull when D will be used for COM or .NET programming or for visual editing of an UI (the inspector will display public (or published) methods (as in Delphi) but not arbitrary method that happen to have the proper number of argument (0 or 1). Also having a keyword would allows support for array properties.

without proper property syntax, what happens with a property or function that returns a class that overloads opCall ?
Sep 20 2003
parent reply "Walter" <walter digitalmars.com> writes:
"Mike Wynn" <mike l8night.co.uk> wrote in message
news:bkj2q9$g5u$1 digitaldaemon.com...
 without proper property syntax,
 what happens with a property or function that returns a class that
 overloads opCall ?

You'll need to have an extra ().
Sep 21 2003
parent reply "Philippe Mori" <philippe_mori hotmail.com> writes:
 without proper property syntax,
 what happens with a property or function that returns a class that
 overloads opCall ?

You'll need to have an extra ().

This is a reason why IMHO it would be better to have a property keyword. That way it would be possible to forward call to an inner class with changing the class interface in the same way that in C++ we can chain operator->. An example: class A { void opCall(int i); } class B { property A prop_name() { return a } A a; } // used that way: B b; b.prop_name(5); // instead of B b; b.prop_name()(5); This make it possible to replace a function by a class without needing the client code to be aware of it... But thinking of it, it would probably caused ambiguities if we allows both syntax (function call vs property)
Sep 21 2003
parent reply Felix <Felix_member pathlink.com> writes:
Why not to use the same definition as in C#? It belongs to MS, but I think is a
good idea.
I have no example now, but simply look in the C# doc.

Just an ideea...

BTW, I hear that Delphi and C# have the same designer?




In article <bklb95$1kcj$1 digitaldaemon.com>, Philippe Mori says...
 without proper property syntax,
 what happens with a property or function that returns a class that
 overloads opCall ?

You'll need to have an extra ().

This is a reason why IMHO it would be better to have a property keyword. That way it would be possible to forward call to an inner class with changing the class interface in the same way that in C++ we can chain operator->. An example: class A { void opCall(int i); } class B { property A prop_name() { return a } A a; } // used that way: B b; b.prop_name(5); // instead of B b; b.prop_name()(5); This make it possible to replace a function by a class without needing the client code to be aware of it... But thinking of it, it would probably caused ambiguities if we allows both syntax (function call vs property)

Sep 21 2003
parent "Walter" <walter digitalmars.com> writes:
"Felix" <Felix_member pathlink.com> wrote in message
news:bkm066$2jer$1 digitaldaemon.com...
 BTW, I hear that Delphi and C# have the same designer?

I think that's correct. The same fellow who did the original Turbo Pascal.
Sep 22 2003
prev sibling next sibling parent reply "Sean L. Palmer" <palmer.sean verizon.net> writes:
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

Sep 19 2003
next sibling parent reply "Walter" <walter digitalmars.com> writes:
"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

 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 +=

 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!
Sep 19 2003
next sibling parent reply "Philippe Mori" <philippe_mori hotmail.com> writes:
 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


 integer amount (not to mention += negative number).

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

I don't want run-time check when a compile-time could have detect the error easily... I would prefer that if would be possible to define opPlusPlus and/or opLessLess if addass is not defined... For operator naming, I would like a syntax similar to the one used in C++ (with some exceptions for cmp for example where operator cmp would be used). For that latter operator, I would say that I would like to have the possibility to be able to define one or two operator among <, <Ş=, > and >= and have the compiler generate the others so that the compiler could generate more efficient code in some cases (one comparison instead of 2) except if you can tell me that the compiler is smart enough to do the optimisation itself...
Sep 19 2003
parent "Sean L. Palmer" <palmer.sean verizon.net> writes:
"Philippe Mori" <philippe_mori hotmail.com> wrote in message
news:bkgg88$28ta$1 digitaldaemon.com...
 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


 integer amount (not to mention += negative number).

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

I don't want run-time check when a compile-time could have detect the error easily...

Good reason!
 I would prefer that if would be possible to define opPlusPlus and/or
 opLessLess if addass is not defined...

Even if it is defined!
 For operator naming, I would like a syntax similar to the one used
 in C++ (with some exceptions for cmp for example where operator
 cmp would be used).

I don't mind C++ syntax for operators. Though heck you could just override + or -- or []. Maybe `+. Maybe this would make everybody else happy, some standard prefix for operators that is in fact a hopefully easy to type symbol that is otherwise unused in D. You could maybe force people to call an overloaded operator by also using the symbol, such as x `+ y or list [3]. But in this case make all the standard operators also be accessible by using the same symbol so templates will be able to differentiate them. Operator overloading is, also, one of the few ways that you can extend one of the builtin types.
 For that latter operator, I would say that I would like to have
 the possibility to be able to define one or two operator among
 <, <Ş=, > and >= and have the compiler generate the others
 so that the compiler could generate more efficient code in
 some cases (one comparison instead of 2) except if you can
 tell me that the compiler is smart enough to do the optimisation
 itself...

The compiler if given enough information can eliminate double-negatives or even single negatives in the generated code when it comes to comparisons and branching. Most compilers routinely do this. If the compiler can't optimize through cmp it may have to do extra work at runtime. Yeah, all you need is one of < and one of =, or one of <=. I wouldn't be surprised if any one of the six can be used to generate all the others. From < you can derive a form of =. But I'd allow explicit specification of any or all of them. Some very complicated comparison (probably bending the rules) might need it. In fact you could represent inexact types by starting off by defining operator <=. Well, > means it's not <=. If a <= b and b <= a, it's probably ==. If not a <= b and not b <= a, it's unordered. I see a logic table forming here. And if you can figure out all 6, you can automatically generate a cmp() function from that. BTW cmp() really only needs to be able to return 3 'bits' of data... == (Z), < (S), ? (O). You can build jae out of !jb, etc. Ideally cmp wouldn't be a member function, so you could specify the operands in either order... currently you'd have to invert the logic when you swap operands. void cmp(in T a, in T b, out bit Z, out bit S, out bit O); I bet Walter is grinning. Sean
Sep 19 2003
prev sibling parent reply "Sean L. Palmer" <palmer.sean verizon.net> writes:
"Walter" <walter digitalmars.com> wrote in message
news:bkfejj$27cl$2 digitaldaemon.com...
 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


 integer amount (not to mention += negative number).

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

So can you ++ floats then? ;) What if I want my class to be able to add, but not ++? For instance if there is no well defined "next" to go to, but you can "add" some arbitrary amount. For instance, maybe a set. Yeah this example is probably an abuse of operator overloading (you'd probably overload ~=). You can add items to a set but can't increment a set. Sean
Sep 19 2003
parent reply "Walter" <walter digitalmars.com> writes:
"Sean L. Palmer" <palmer.sean verizon.net> wrote in message
news:bkgj6v$2k11$1 digitaldaemon.com...
 So can you ++ floats then?  ;)

Yes.
 What if I want my class to be able to add, but not ++?  For instance if
 there is no well defined "next" to go to, but you can "add" some arbitrary
 amount.  For instance, maybe a set.  Yeah this example is probably an

 of operator overloading (you'd probably overload ~=).  You can add items

 a set but can't increment a set.

This goes back to what I think operator overloading should be for. It should be for adding (!) arithmetic to user defined data types. I think it is not appropriate to overload << to be anything but a shift operation, i.e. using it as 'insert' is just not right. I don't agree with the notion that, for example, ++ could be overloaded to mean 'get the next item in the list'. This is reflected in the design of the operator overloading in D, such as + is commutative and / is not. It is not meant to support the notion that ++ is fundamentally different from +=. I think operator overloading should be used much more conservatively than how it is popularly used in C++. People shouldn't have to look for an operator overload of += to find out that what it is doing has nothing at all to do with adding.
Sep 19 2003
next sibling parent reply "Matthew Wilson" <matthew stlsoft.org> writes:
 This goes back to what I think operator overloading should be for. It

 be for adding (!) arithmetic to user defined data types. I think it is not
 appropriate to overload << to be anything but a shift operation, i.e.

 it as 'insert' is just not right. I don't agree with the notion that, for
 example, ++ could be overloaded to mean 'get the next item in the list'.

 This is reflected in the design of the operator overloading in D, such as

 is commutative and / is not. It is not meant to support the notion that ++
 is fundamentally different from +=. I think operator overloading should be
 used much more conservatively than how it is popularly used in C++. People
 shouldn't have to look for an operator overload of += to find out that

 it is doing has nothing at all to do with adding.

Quite right. Transgressors should be weeded out and forced to 3yrs hard VB.NET before they're allowed back on parole
Sep 19 2003
next sibling parent "Walter" <walter digitalmars.com> writes:
"Matthew Wilson" <matthew stlsoft.org> wrote in message
news:bkgocr$3j7$1 digitaldaemon.com...
 Quite right. Transgressors should be weeded out and forced to 3yrs hard
 VB.NET before they're allowed back on parole

I never knew you were so cruel <g>.
Sep 20 2003
prev sibling parent reply "Sean L. Palmer" <palmer.sean verizon.net> writes:
"Matthew Wilson" <matthew stlsoft.org> wrote in message
news:bkgocr$3j7$1 digitaldaemon.com...
 is fundamentally different from +=. I think operator overloading should


 used much more conservatively than how it is popularly used in C++.


 shouldn't have to look for an operator overload of += to find out that


 it is doing has nothing at all to do with adding.

Quite right. Transgressors should be weeded out and forced to 3yrs hard VB.NET before they're allowed back on parole

In my own module, I should be able to do whatever I please, whatever makes solving the task at hand easier. Who are you to dictate to me how I should program? Who the hell do you think you are? If I expose this stuff to you, and you don't like it, feel free to not use my library. Sean
Sep 20 2003
parent reply Mike Wynn <mike l8night.co.uk> writes:
Sean L. Palmer wrote:
 "Matthew Wilson" <matthew stlsoft.org> wrote in message
 news:bkgocr$3j7$1 digitaldaemon.com...
 
is fundamentally different from +=. I think operator overloading should


be
used much more conservatively than how it is popularly used in C++.


People
shouldn't have to look for an operator overload of += to find out that


what
it is doing has nothing at all to do with adding.

Quite right. Transgressors should be weeded out and forced to 3yrs hard VB.NET before they're allowed back on parole

In my own module, I should be able to do whatever I please, whatever makes solving the task at hand easier. Who are you to dictate to me how I should program? Who the hell do you think you are?

you have already allowed Walter to dictated to you how you program, by chosing his language to use. what you write in your own module is upto you, but if you are making it public, then you might want to listen to what those who might be using it are saying. are you that well intune with D to understand the effects and implications of operator overloading for instance, although virtual, which "virtual" method to call is statically determined and have you made your users aware of the side effects of your use of overloading.
 If I expose this stuff to you, and you don't like it, feel free to not use
 my library.
 

Sep 20 2003
parent "Pizaz" <me here.com> writes:
"Mike Wynn" <mike l8night.co.uk> wrote in message
news:bkib7u$2ilb$1 digitaldaemon.com...
 Sean L. Palmer wrote:
<snip>
 In my own module, I should be able to do whatever I please, whatever


 solving the task at hand easier.  Who are you to dictate to me how I


 program?  Who the hell do you think you are?


/me steps inbetween Mike and Sean and says: "SO HOW ABOUT THEM SEATTLE SEAHAWKS?" :)
 you have already allowed Walter to dictated to you how you program, by
 chosing his language to use.

 what you write in your own module is upto you, but if you are making it
 public, then you might want to listen to what those who might be using
 it are saying.

Sep 20 2003
prev sibling next sibling parent reply "Sean L. Palmer" <palmer.sean verizon.net> writes:
"Walter" <walter digitalmars.com> wrote in message
news:bkgnd1$cd$1 digitaldaemon.com...
 "Sean L. Palmer" <palmer.sean verizon.net> wrote in message
 news:bkgj6v$2k11$1 digitaldaemon.com...
 So can you ++ floats then?  ;)

Yes.
 What if I want my class to be able to add, but not ++?  For instance if
 there is no well defined "next" to go to, but you can "add" some


 amount.  For instance, maybe a set.  Yeah this example is probably an

 of operator overloading (you'd probably overload ~=).  You can add items

 a set but can't increment a set.

This goes back to what I think operator overloading should be for. It

 be for adding (!) arithmetic to user defined data types. I think it is not
 appropriate to overload << to be anything but a shift operation, i.e.

 it as 'insert' is just not right. I don't agree with the notion that, for
 example, ++ could be overloaded to mean 'get the next item in the list'.

That's your prerogative. But despite what *you* think operator overloading *should* be for, people will see it as a tool, and if the tool allows them to do what they want to do, they'll use it. People have found all kinds of inventive uses for operator overloading in C++, and though you and your camp cringe when they see this, and curse them, the other camp sees this as innovative and stylish and concise. ;) Fact is, people are always taught programming of named functions, but operators are just as much functions as ones with names. Many many problems are better solved symbolically than with longwinded names. The problem in C++ is that there aren't enough operators available for overloading and so people have to abuse the ones that *are* provided. That said, you are the designer of D, and you are free to do as you wish.
 This is reflected in the design of the operator overloading in D, such as

 is commutative and / is not. It is not meant to support the notion that ++
 is fundamentally different from +=. I think operator overloading should be
 used much more conservatively than how it is popularly used in C++. People
 shouldn't have to look for an operator overload of += to find out that

 it is doing has nothing at all to do with adding.

You could say this about any function call. Functions are just a little easier to search for, is all. People need to RTFM and not just assume they can look at something and understand it. There is often more than meets the eye, even in normal functional or OO programs. If ++x is converted to x += 1 automatically, then what if you overload operator + to take something besides int type? And if you do mapp ++x to x += 1, then you should also automatically map x++ to temp = x, x += 1, temp, and similarly for x-- 99% of the time what I do want to use overloading for IS a mathematical type. But I've seen some really neat stuff done with operator overloading, things that the inventors would never have considered. Perhaps you could allow a bunch of other operators available for overloading that people could do with as they pleased? Maybe `+` or `,`? Nah, looks too much like a character literal. Maybe any normal D operator surrounded by periods, or colons? Sean
Sep 20 2003
parent reply "Walter" <walter digitalmars.com> writes:
"Sean L. Palmer" <palmer.sean verizon.net> wrote in message
news:bki5gj$2apn$1 digitaldaemon.com...
 If ++x is converted to x += 1 automatically, then what if you overload
 operator + to take something besides int type?

 And if you do mapp ++x to x += 1, then you should also automatically map

 to temp = x, x += 1, temp, and similarly for x--

 99% of the time what I do want to use overloading for IS a mathematical
 type.  But I've seen some really neat stuff done with operator

 things that the inventors would never have considered.

There is always that risk that perhaps this shuts the door on something. But although I don't agree with using arithmetic operator overloading for non-arithmetic purposes, that's a purely stylistic issue. Sorry if my opinions come on a little strong about it sometimes. What the arithmetic operator overloading rules do, however, is make it much easier to make a user-defined arithmetic type and integrate it into the language. For example, only one comparison operator needs to be written, rather than the 8 in C++.
Sep 20 2003
next sibling parent "Philippe Mori" <philippe_mori hotmail.com> writes:
 There is always that risk that perhaps this shuts the door on something.

 although I don't agree with using arithmetic operator overloading for
 non-arithmetic purposes, that's a purely stylistic issue. Sorry if my
 opinions come on a little strong about it sometimes. What the arithmetic
 operator overloading rules do, however, is make it much easier to make a
 user-defined arithmetic type and integrate it into the language. For
 example, only one comparison operator needs to be written, rather than the

 in C++.

IMHO, how the operators works is a property of the class (this include assignment, creation,...) and we either tag the class with an attribute when we want something different than the default (which should be conservative and safe) or it should be expressed by the functions (and their attibutes) that are prent in the class. We should be able to detect if a class support a concept without requiring an interface (and a virtual table). We do not necessarily need MI but we should be able to associate some characteristics to a class (or the compiler should be able to tell us from the definition). I want to be able to know if a class is comparable (and if so, which king of comparison are allowed, equality only, fully ordered or partly ordered), copyable (if so, if bitwise for struct, deeep, shalow,...), createable on stack (auto) or dynamically, assignable, if it might be null, ... For the operator, it is true that in C++, not enough operators are defined in terms of others but I think we should have some control of what we allows and which operators are always or sometimes defined in term of others... I think the best solution would be to do almost nothing by default but provide an easy way to get many things done by the compiler... This could be done in a few ways. Here are some possibilities: a) We have some class attributes (or the possibility to inherit from some special "capability declaration classes" that would tell how some operators (and other functions) are handled: class A : fully_ordered, deep_copy, standard_arithmetic { } where theses bases classes would give constraints or capabilities or behaviors of the classes. A constraint class cannot have virtual member nor data member (i.e always a empty-base) but would only have declarations and template style definitions. We would provide a few such constraint classes in the standard library. Here an example (the syntax may have some errors but it should give the idea) : constraint class fully_ordered { // derived indicate that the type must be a derived class... template (T:derived) int cmp(T t1, T t2); // declaration only // Here is is a sample on how we could prevent (we might // also simply uses private access) but exactly what we // give might vary a bit (we could in particular have // one safe class and another one that do more thing // automatically. template (T:derived, U:derived) prohibited int cmp(T t, U u); // declaration -- prevent mixed derived classes template (T:derived) bool operator < (T t1, T t2) { return cmp(t1, t2) < 0; } template (T:derived) bool operator <= (T t1, T t2) { return cmp(t1, t2) <= 0; } template (T:derived) bool operator > (T t1, T t2) { return cmp(t1, t2) > 0; } template (T:derived) bool operator >= (T t1, T t2) { return cmp(t1, t2) >= 0; } // Have a way to check if a type has a member (or free) function // and if so, uses that specialisation... // The syntax need reworking -- I uses plain english to give the // concept. The idae is simply to be able to specialize on something // more than T* or MyClass* or something similar template (T : derived where T has (eq)) bool operator==(T t1, T t2) { return eq(t1, t2); } // This is the normal definition uses when the specialisation // do not apply. template (T : derived ) bool operator==(T t1, T t2) { return cmp(t1, t2); } template (T: derived) bool operator!=(T t1, T t2) { return !(t1 == t2); } } constraint_class fully_ordered_less { // Similar to above but uses a member function less // to implement all operators. // In fact, we could merge that constraint class with the // previous and check for the presence of members // eq(), cmp() and less() to decide what we do (and // we could even prohibit having both operator less and // cmp defined if we want by making a specialisation // when both are defined and prohibiting it... // In fact, it be usefull in that case to prohibit class instanciation // even if no comparison are ever done.. // Maybe we would also like to be able to put contraints // that make the class abstract is something is not defined... } The advantage of doing is that way is clear... We can provide a class with the most usefull rules so that it would be very easy to uses them but it is possible to define our owns constraint classes (for example one that would works with partial order). Also, it is possible to group those class: constraint class fully_ordered_with_deep_copy : fully_ordered, deeep_copy { } and when we want to uses a class, we simply specify those classes as if we inherit from them. class A : fully_ordered { int cmp(...) { definition here... } }; With such a concept of constraint classes, we add lot of power to the language as those classes would be used to: a) automatically implement some operations in term of others b) verify that a class define something (similar to an abstract method) c) verify some other constraint on a type... Also, it would be easy if one want operator ++ to means += 1 to have one such class and one other if we don't want it... By default, I would say that classes would be relatively restricted if the do not inherited from such a class (to be the safest by default). We might even prohibit some kind of operations if we do not inherit from a class that enable it... (for ex. no operator cmp if we do not have a constraint class that define its behavior) We would have a language that would allows to express lot of things directly in the code...
Sep 20 2003
prev sibling parent reply "Sean L. Palmer" <palmer.sean verizon.net> writes:
"Walter" <walter digitalmars.com> wrote in message
news:bkim0p$30sm$1 digitaldaemon.com...
 "Sean L. Palmer" <palmer.sean verizon.net> wrote in message
 news:bki5gj$2apn$1 digitaldaemon.com...
 If ++x is converted to x += 1 automatically, then what if you overload
 operator + to take something besides int type?

 And if you do mapp ++x to x += 1, then you should also automatically map

 to temp = x, x += 1, temp, and similarly for x--

 99% of the time what I do want to use overloading for IS a mathematical
 type.  But I've seen some really neat stuff done with operator

 things that the inventors would never have considered.

There is always that risk that perhaps this shuts the door on something.

 although I don't agree with using arithmetic operator overloading for
 non-arithmetic purposes, that's a purely stylistic issue. Sorry if my
 opinions come on a little strong about it sometimes. What the arithmetic
 operator overloading rules do, however, is make it much easier to make a
 user-defined arithmetic type and integrate it into the language. For
 example, only one comparison operator needs to be written, rather than the

 in C++.

I'm not really against it in some cases. I'm just not sure ++ == +1 is a good one. It seems unbalanced. Sean
Sep 20 2003
parent "Philippe Mori" <philippe_mori hotmail.com> writes:
 I'm not really against it in some cases.  I'm just not sure ++ == +1 is a
 good one.  It seems unbalanced.

 Sean

I would say that it should be possible to define ++ or -- if += or -= is not defined for a type (like it would be the case for an iterator in C++ STL that is not a random iterator). In those case, we might prefer to have only ++ and/or -- defined. OTOH, always defining ++ from += (if that one is defined), is not a good idea either... For example, the following will loop infinitly and it might not be desirable that the code compile than way: for (double d = 1e16; d < 1.01e16; ++d) { // Do something with d... } Also for some type like an enum (or a class that would emulate it if it does not apply), it is simpler to implement increment by one that by an arbitrary number... IMO, if we support both eq and cmp for a class at the same time, why for ++ and +=, they must always be defined one in the term of the other ? On that issues, if cmp is implemented for a type but not eq, will eq, == and != be implemented in terms of cmp ?
Sep 21 2003
prev sibling parent reply J Anderson <anderson badmama.com.au.REMOVE> writes:
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
  <title></title>
</head>
<body text="#000000" bgcolor="#ffffff">
Walter wrote:<br>
<blockquote type="cite" cite="midbkgnd1$cd$1 digitaldaemon.com">
  <pre wrap="">"Sean L. Palmer" <a class="moz-txt-link-rfc2396E"
href="mailto:palmer.sean verizon.net">&lt;palmer.sean verizon.net&gt;</a> wrote
in message
<a class="moz-txt-link-freetext"
href="news:bkgj6v$2k11$1 digitaldaemon.com">news:bkgj6v$2k11$1 digitaldaemon.com</a>...
  </pre>
  <blockquote type="cite">
    <pre wrap="">So can you ++ floats then?  ;)
    </pre>
  </blockquote>
  <pre wrap=""><!---->
Yes.

  </pre>
  <blockquote type="cite">
    <pre wrap="">What if I want my class to be able to add, but not ++?  For
instance if
there is no well defined "next" to go to, but you can "add" some arbitrary
amount.  For instance, maybe a set.  Yeah this example is probably an
    </pre>
  </blockquote>
  <pre wrap=""><!---->abuse
  </pre>
  <blockquote type="cite">
    <pre wrap="">of operator overloading (you'd probably overload ~=).  You can
add items
    </pre>
  </blockquote>
  <pre wrap=""><!---->to
  </pre>
  <blockquote type="cite">
    <pre wrap="">a set but can't increment a set.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
This goes back to what I think operator overloading should be for. It should
be for adding (!) arithmetic to user defined data types. I think it is not
appropriate to overload &lt;&lt; to be anything but a shift operation, i.e.
using
it as 'insert' is just not right. I don't agree with the notion that, for
example, ++ could be overloaded to mean 'get the next item in the list'.

This is reflected in the design of the operator overloading in D, such as +
is commutative and / is not. It is not meant to support the notion that ++
is fundamentally different from +=. I think operator overloading should be
used much more conservatively than how it is popularly used in C++. People
shouldn't have to look for an operator overload of += to find out that what
it is doing has nothing at all to do with adding.

  </pre>
</blockquote>
I agree, you shouldn't need to have to look at to much documentation to
realize what some operator does.&nbsp; By restricting how each operator
interacts, they each develop their own behavior which can be quickly
recognized by the average coder.&nbsp; <br>
<br>
Of course there are always are situations where&nbsp; you run out of symbols
for the particular behavior needed.&nbsp; In these cases the programmer
generally falls back to, methods, or proxy objects.<br>
<br>
Parhaps allowing extended operators, in array form, or using colon...<br>
<br>
x = x +[2] y; //Powerful but ugly<br>
x = x +[LIST_OPS_2] y; //Then they'd want to use variables, with them
(why not use methods in the first place).<br>
<br>
or<br>
x = (x + y)[2];<br>
or<br>
x = x :+: y; //Probably the neatest form<br>
or<br>
x = x .+ y; //Mixed up with float point?<br>
or<br>
x = x plus[2] y; //Don't use symbols at all.<br>
<br>
...nar IMHO, that'd make D begin to look like ugly machine code.<br>
<br>
I think it's best to stick with how it works now&nbsp;<span
 class="moz-smiley-s3"><span> ;-) </span></span>
</body>
</html>
Sep 20 2003
parent "Philippe Mori" <philippe_mori hotmail.com> writes:
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

x =3D x :+: y; //Probably the neatest form

I like the idea of being able to define our own operators. This could be =

done by using :something: as youi suggest or we might also uses
another symbol like  , # or $ to start a user symbol and we could
allows most characters that are used in operators and any valid=20
name (we migth have some restrictions on what symbols are
allowed and not allowing mixing symbol (like +, <) with names.

Using a trailing symbol does have an advantage of limiting possible=20
ambiguities if we want to allows no space after the operator.

For example, I would be able to define an exponent operator

5.1  pow 2    // 5.1 ^ 2 (i.e. 5.1 * 5.1)

Matrix m;

 det m;    // determinant of the matrix m
    // where  det is defined as a prefix operator of class Matrix


When a user defined operator is found, the compiler would=20
suppose binary operator if there is an expression on both side
a prefix operator if there is an expression on the right and a a=20
postfix operator if there is an expression on the left.

a +  my_op b;     my_op is a prefix op for object of type b
a  my_op b;     my_op is a binary op
a  my_op + b;     my_op is a postfix op for object of type a
Sep 20 2003
prev sibling parent reply John Boucher <John_member pathlink.com> writes:
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.
Sep 19 2003
parent "Sean L. Palmer" <palmer.sean verizon.net> writes:
That is an interesting idea!  It's a very common operation.

Sean

"John Boucher" <John_member pathlink.com> wrote in message
news:bkfh2j$2dd4$1 digitaldaemon.com...
 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!!

Sep 19 2003
prev sibling next sibling parent reply "Jeroen van Bemmel" <someone somewhere.com> writes:
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

Sep 19 2003
parent reply "Walter" <walter digitalmars.com> writes:
"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

 comparison operators <, >, <= and >= are not commutative?

Sure they are! a < b and b > a
Sep 19 2003
next sibling parent reply "Jeroen van Bemmel" <someone somewhere.com> writes:
 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
Sep 19 2003
parent reply "Walter" <walter digitalmars.com> writes:
"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 <=.
Sep 19 2003
parent reply "Jeroen van Bemmel" <someone somewhere.com> writes:
 In a mathematical sense you're right, but I just turn < into > to swap the
 operands, and >= into <=.

OK, so they are like 'commutable'. Isn't this confusing in the context of overloading? When do you do this implicit transformation, in the optimizer? I noticed all these operators map to 'cmp', so 'cmp' should return -1,0,+1 or something? I must say this new operator overloading feature doesn't really appeal to me. It seems like there is more complexity and caveats being added than benefits (syntactic sugar)
Sep 20 2003
parent "Walter" <walter digitalmars.com> writes:
"Jeroen van Bemmel" <someone somewhere.com> wrote in message
news:bkh5rd$1269$1 digitaldaemon.com...
 In a mathematical sense you're right, but I just turn < into > to swap


 operands, and >= into <=.

overloading? When do you do this implicit transformation, in the

No, in the semantic phase.
 I noticed all these operators map to 'cmp', so 'cmp' should return -1,0,+1
 or something?

All it needs to return is an int less than 0, 0, or greater than 0. Think of it like the strcmp() function in C.
 I must say this new operator overloading feature doesn't really appeal to
 me. It seems like there is more complexity and caveats being added than
 benefits (syntactic sugar)

One benefit is only one cmp function needs to be written instead of the 8 in C++ <g>. Remember, though, that == and != are handled by eq(), not cmp(). This is because it is common for a type to have an equality characteristic, but a relational characteristic would make no sense.
Sep 20 2003
prev sibling parent reply Antti =?iso-8859-1?Q?Syk=E4ri?= <jsykari gamma.hut.fi> writes:
In article <bkfejk$27cl$3 digitaldaemon.com>, Walter wrote:
 
 "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

 comparison operators <, >, <= and >= are not commutative?

Sure they are! a < b and b > a

The mathematical term would be "anticommutative". "An operator * for which a * b = -b * a is said to be anticommutative" http://mathworld.wolfram.com/Anticommutative.html -Antti
Sep 21 2003
next sibling parent reply "Walter" <walter digitalmars.com> writes:
"Antti Sykńri" <jsykari gamma.hut.fi> wrote in message
news:slrnbmr5a2.qqp.jsykari pulu.hut.fi...
 The mathematical term would be "anticommutative".

 "An operator * for which

 a * b = -b * a

 is said to be anticommutative"

 http://mathworld.wolfram.com/Anticommutative.html

I didn't know that! Thanks for the pointer.
Sep 21 2003
next sibling parent reply Mike Wynn <mike l8night.co.uk> writes:
Walter wrote:
 "Antti Sykńri" <jsykari gamma.hut.fi> wrote in message
 news:slrnbmr5a2.qqp.jsykari pulu.hut.fi...
 
The mathematical term would be "anticommutative".

"An operator * for which

a * b = -b * a

is said to be anticommutative"

http://mathworld.wolfram.com/Anticommutative.html

I didn't know that! Thanks for the pointer.

isn't that -... realy the inverse of ... for op * and is it a * b = inv(b) * a or is it a * b = inv (b*a) (the latter is true for subtraction and division)
Sep 21 2003
parent Antti =?iso-8859-1?Q?Syk=E4ri?= <jsykari gamma.hut.fi> writes:
In article <bkkt1b$112p$1 digitaldaemon.com>, Mike Wynn wrote:
 Walter wrote:
 "Antti Sykńri" <jsykari gamma.hut.fi> wrote in message
 news:slrnbmr5a2.qqp.jsykari pulu.hut.fi...
 
The mathematical term would be "anticommutative".

"An operator * for which

a * b = -b * a

is said to be anticommutative"

http://mathworld.wolfram.com/Anticommutative.html



It seems I was kind of tired when I posted that (not that the situationis much better now). On the second thought, the term does not apply. I recall We were having a < b == b > a and here < and > are different operators (relations, actually) but the anticommutativity only talks about one. And still it wouldn't work, except in some weird boolean algebra where "-" means not and where "a = b" never holds. What is anticommutative, though, is the cmp() function.
 I didn't know that! Thanks for the pointer.
 
 

isn't that -... realy the inverse of ... for op * and is it a * b = inv(b) * a or is it a * b = inv (b*a) (the latter is true for subtraction and division)

With subtraction and division, the operator just makes its right side into its inverse under the operation and then does the normal operation (addition for -, multiplication for /). So at least the latter identity is true (at least as long if the normal operation commutes). But I think we're talking about a pretty thin abstraction here, if you can use the term in mathematics. Something that can be derived from the ring axioms (or was it something less than that? Semi-ring? Group? Too tired for that..) (Anticommutativity might be more interesting... interestingly, the keyword finds only two pages in MathWorld, Lagrange Brackets and Poisson Brackets. Stuff that I recall having studied once at the theoretical physics course) -Antti
Sep 21 2003
prev sibling parent "Sean L. Palmer" <palmer.sean verizon.net> writes:
"Walter" <walter digitalmars.com> wrote in message
news:bkkqg3$tjd$2 digitaldaemon.com...
 "Antti Sykńri" <jsykari gamma.hut.fi> wrote in message
 news:slrnbmr5a2.qqp.jsykari pulu.hut.fi...
 The mathematical term would be "anticommutative".

 "An operator * for which

 a * b = -b * a

 is said to be anticommutative"

 http://mathworld.wolfram.com/Anticommutative.html

I didn't know that! Thanks for the pointer.

There is actually some really important cool stuff that depends on anticommutativity. Geometric algebra is based on it. So any optimizations you do on operator * like swapping the inputs is going to cause problems with people trying to use operator * to implement say, geometric product, which is anticommutative. We either need another operator or even better would be the ability to specify the behavior of the operators as we overload them. precedence, associativity, fixity, commutativity, etc. Sean
Sep 22 2003
prev sibling parent reply "Daniel Yokomiso" <daniel_yokomiso yahoo.com.br> writes:
"Antti Sykńri" <jsykari gamma.hut.fi> escreveu na mensagem
news:slrnbmr5a2.qqp.jsykari pulu.hut.fi...
 In article <bkfejk$27cl$3 digitaldaemon.com>, Walter wrote:
 "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

 comparison operators <, >, <= and >= are not commutative?

Sure they are! a < b and b > a

The mathematical term would be "anticommutative". "An operator * for which a * b = -b * a is said to be anticommutative" http://mathworld.wolfram.com/Anticommutative.html -Antti

Hmmm, I think the correct definition would be "antisymmetric", for the cmp operation. We can just assume cmp behaving as a infinite matrix and the parameters are the possible indices (or something like that ;) http://mathworld.wolfram.com/Antisymmetric.html --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.520 / Virus Database: 318 - Release Date: 18/9/2003
Sep 21 2003
parent Felix <Felix_member pathlink.com> writes:
AFAIK:

< and > are not ordinal operators, are strict ordinal operators.

The right term for <= and >= is "antisimetric" ( OK, with bad english )
i.e.:

a<=b AND b<=a => a=b (necessarily).

So, an op is antisimetric if "a OP b" and "b OP a" involves "a=b"



In article <bklaa0$1iue$1 digitaldaemon.com>, Daniel Yokomiso says...
"Antti Sykńri" <jsykari gamma.hut.fi> escreveu na mensagem
news:slrnbmr5a2.qqp.jsykari pulu.hut.fi...
 In article <bkfejk$27cl$3 digitaldaemon.com>, Walter wrote:
 "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

 comparison operators <, >, <= and >= are not commutative?

Sure they are! a < b and b > a

The mathematical term would be "anticommutative". "An operator * for which a * b = -b * a is said to be anticommutative" http://mathworld.wolfram.com/Anticommutative.html -Antti

Hmmm, I think the correct definition would be "antisymmetric", for the cmp operation. We can just assume cmp behaving as a infinite matrix and the parameters are the possible indices (or something like that ;) http://mathworld.wolfram.com/Antisymmetric.html --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.520 / Virus Database: 318 - Release Date: 18/9/2003

Sep 21 2003
prev sibling next sibling parent Mike Wynn <mike l8night.co.uk> writes:
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]$
Sep 19 2003
prev sibling next sibling parent Mike Wynn <mike l8night.co.uk> writes:
Walter wrote:
 Some long awaited features.
 
 http://www.digitalmars.com/d/changelog.html
 

is this the "correct" responce from D ? class A { int tag; this( int tag0 ) { tag = tag0; } void dump() { printf("A:%d\n", tag); } } class C : A { int tagw; this( int tag0 ) { super( tag0+100);tagw = tag0; } void dump() { printf("C:%d\n", tagw); } } class B { this() { } A add( B b ) { return new A(3); } A add( D b ) { return new A(2); } } class D : B { this() { } C add( B b ) { return new C(4); } C add( D b ) { return new C(5); } } int main( char[][] argv ) { D d = new D(); B b = d; A a; a = b + b; a.dump(); a = b + d; a.dump(); a = d + d; a.dump(); a = d + b; a.dump(); return 1; } ---- output ---- C:4 C:5 C:5 C:4 ------------------ test 2 ----------------- class A { int tag; this( int tag0 ) { tag = tag0; } void dump() { printf("A:%d\n", tag); } } class C : A { int tagw; this( int tag0 ) { super( tag0+100);tagw = tag0; } void dump() { printf("C:%d\n", tagw); } } class B { this() { } A add( B b ) { return new A(3); } // A add( D b ) { return new A(2); } } class D : B { this() { } C add( B b ) { return new C(4); } C add( D b ) { return new C(5); } } int main( char[][] argv ) { D d = new D(); B b = d; A a; a = b + b; a.dump(); a = b + d; a.dump(); a = d + d; a.dump(); a = d + b; a.dump(); return 1; } -------------- op ----------------- C:4 C:4 C:5 C:4 ---------------- test 3 -------------- class B { this() { } A add( B b ) { return new A(3); } // A add( D b ) { return new A(2); } } class D : B { this() { } // C add( B b ) { return new C(4); } C add( D b ) { return new C(5); } } will not compile all +'s :
 opvl.d(36): function add (D b) does not match argument types (B )

----------------- test 3a --------------- class A { int tag; this( int tag0 ) { tag = tag0; } void dump() { printf("A:%d\n", tag); } } class C : A { int tagw; this( int tag0 ) { super( tag0+100);tagw = tag0; } void dump() { printf("C:%d\n", tagw); } } class B { this() { } A add( B b ) { return new A(3); } // A add( D b ) { return new A(2); } } class D : B { this() { } // C add( B b ) { return new C(4); } C add( D b ) { return new C(5); } } int main( char[][] argv ) { D d = new D(); B b = d; A a; a = b + b; a.dump(); a = b + d; a.dump(); a = d + d; a.dump(); // a = d + b; // a.dump(); return 1; } -------op----
 A:3
 A:3
 C:5

Sep 19 2003
prev sibling next sibling parent Mike Wynn <mike l8night.co.uk> writes:
Walter wrote:
 Some long awaited features.
 
 http://www.digitalmars.com/d/changelog.html
 
 
 

why is opIndex( T idx ) only? Basic uses () for array indexing .... you can fake it all with opCall .... and by returning a T* allow read/write as in this simple 2d array class ... not sure if opIndex is redundant or if it should allow multipul indexors import c.stdio; class B { int[] data; int lw; this( int xw, int yw ) { lw = xw; data=new int[xw*yw]; } int[] opCall( int y ) { return this[y]; } int * opCall( int x, int y ) { return &data[(y*lw)+x]; } int[] opIndex( int y ) { return data[(y*lw)..((y*lw)+lw)]; } void dump() { printf( "data [" ); foreach( int v; data ) { printf( "%d, ", v ); } printf( "]\n" ); } } int main( char[][] argv ) { B b = new B( 2, 2 ); int[] ar = b[0]; printf("ar.length:%d\n", ar.length); ar[0] = 1; ar[1] = 2; *(b(1,1)) =3; *(b(0,1)) =-4; b.dump(); return 1; } --------- however the old slice append overrunn bug/feature occurs --- int main( char[][] argv ) { B b = new B( 2, 2 ); int[] ar = b[0]; printf("ar.length:%d\n", ar.length); ar[0] = 1; ar[1] = 2; *(b(1,1)) =3; *(b(0,1)) =-4; b.dump(); ar ~= 100; b.dump(); return 1; } outputs
 ar.length:2
 data [1, 2, -4, 3, ]
 data [1, 2, 100, 3, ]

Sep 19 2003
prev sibling next sibling parent reply "Matthew Wilson" <matthew stlsoft.org> writes:
Bug:

What was

    foreach(Value value; key.propget_Values())

is now

    foreach(Value value; key.Values)

Looks nice. Doesn't compile. :(

    "win32_reg_test.d(15): foreach: ValueSequence () is not an aggregate
type"

It works ok if I change the code to

    ValueSequence values = key.Values;

    foreach(Value value; values)

but that spoils the fun a little. :)

This is not a great emergency, since the above workaround is eminently
reasonable. However, it'd be good if it could be fixed in 0.74



"Walter" <walter digitalmars.com> wrote in message
news:bked8d$2pe5$1 digitaldaemon.com...
 Some long awaited features.

 http://www.digitalmars.com/d/changelog.html

Sep 19 2003
parent reply "Walter" <walter digitalmars.com> writes:
"Matthew Wilson" <matthew stlsoft.org> wrote in message
news:bkgin8$2hs0$1 digitaldaemon.com...
 This is not a great emergency, since the above workaround is eminently
 reasonable. However, it'd be good if it could be fixed in 0.74

No problem. I expect problems like that to crop up on the first try at a great new feature!
Sep 19 2003
parent "Matthew Wilson" <matthew stlsoft.org> writes:
"Walter" <walter digitalmars.com> wrote in message
news:bkgnd2$cd$2 digitaldaemon.com...
 "Matthew Wilson" <matthew stlsoft.org> wrote in message
 news:bkgin8$2hs0$1 digitaldaemon.com...
 This is not a great emergency, since the above workaround is eminently
 reasonable. However, it'd be good if it could be fixed in 0.74

No problem. I expect problems like that to crop up on the first try at a great new feature!

Even if you do say so yourself, arf arf. :) (You're right, however)
Sep 19 2003
prev sibling next sibling parent reply Mike Wynn <mike l8night.co.uk> writes:
Walter wrote:
 Some long awaited features.
 
 http://www.digitalmars.com/d/changelog.html
 

is it just me or is int opSlice() pointless ? I've written a copy on extend slice class but howcan I write the overloaded operator to allow a[]=b[]; to work as it does for arrays there is no operator =/assign this simple addition would allow opIndex to return a "ref" class (although does require operator toType/cast to allow template lists(T) { class ref { T* ptr; this( T* ptr0 ) { ptr = ptr0; } operator T { return *ptr; } operator = ( T v ) { *ptr = v; } } class vector { T[] data; this( int len ) { data = new T[len]; } ref opIndex( int i ) { return new ref( &t[i] ); } } } instance lists(int).vector ar = new instance lists(int).vector(3); int a = ar[2]; ar[1] = 33; as overloading int * opCall( int i ) { return &t[i]; } does not allow detection of writes
Sep 19 2003
next sibling parent Mike Wynn <mike l8night.co.uk> writes:
Mike Wynn wrote:
 Walter wrote:
 
 Some long awaited features.

 http://www.digitalmars.com/d/changelog.html

is it just me or is int opSlice() pointless ? I've written a copy on extend slice class but howcan I write the overloaded operator to allow a[]=b[]; to work as it does for arrays there is no operator =/assign this simple addition would allow opIndex to return a "ref" class (although does require operator toType/cast to allow template lists(T) { class ref { T* ptr; this( T* ptr0 ) { ptr = ptr0; } operator T { return *ptr; } operator = ( T v ) { *ptr = v; } } class vector { T[] data; this( int len ) { data = new T[len]; } ref opIndex( int i ) { return new ref( &t[i] ); } } } instance lists(int).vector ar = new instance lists(int).vector(3); int a = ar[2]; ar[1] = 33; as overloading int * opCall( int i ) { return &t[i]; } does not allow detection of writes

forgot .. this was as far as my experiment went ... import c.stdio; template Coe( T ) { class Block { T[] slice; bit copyneeded; this( T[] from ) { slice = from; copyneeded = true; } T opCall( int i ) { return slice[i]; } T opIndex( int i ) { return slice[i]; } T opIndex( int i, T v ) { return (slice[i] = v); } void catass( T v ) { if ( copyneeded ) { slice = slice.dup; copyneeded = false; } slice ~= v; } int length() { return slice.length; } int apply( int delegate( inout T ) func ){ foreach( inout T t; slice ) { int i; i = func( t ); if ( i ) { return i; } } return 0; } } } class B { alias instance Coe( int ).Block BA; int[] data; int lw; this( int xw, int yw ) { lw = xw; data=new int[xw*yw]; } BA opCall( int y ) { return this[y]; } // int opCall( int x, int y ) { return this[y][x]; } int * opCall( int x, int y ) { return &data[(y*lw)+x]; } BA opIndex( int y ) { return new BA(data[(y*lw)..((y*lw)+lw)]); } void dump() { printf( "data [" ); foreach( int v; data ) { printf( "%d, ", v ); } printf( "]\n" ); } } int main( char[][] argv ) { B b = new B( 2, 2 ); B.BA ar = b[0]; printf("ar.length:%d\n", ar.length); ar[0] = 1; ar[1] = 2; *(b(1,1)) =3; *(b(0,1)) =-4; b.dump(); ar ~= 100; b.dump(); printf( "ar[" ); foreach( int i; ar ) { printf( "%d, ", i ); } printf( "]\n" ); return 1; }
Sep 19 2003
prev sibling parent "Walter" <walter digitalmars.com> writes:
"Mike Wynn" <mike l8night.co.uk> wrote in message
news:bkgk91$2nvf$1 digitaldaemon.com...
 Walter wrote:
 Some long awaited features.

 http://www.digitalmars.com/d/changelog.html

is it just me or is int opSlice() pointless ? I've written a copy on extend slice class but howcan I write the overloaded operator to allow a[]=b[]; to work as it does for arrays there is no operator =/assign

Looks like I need to add something for that here.
Sep 19 2003
prev sibling next sibling parent Mike Wynn <mike l8night.co.uk> writes:
Walter wrote:
 Some long awaited features.
 
 http://www.digitalmars.com/d/changelog.html
 
 
 

the following code will create Internal error: e2ir.c 721 Linux (RH9) dmd 0.73 /* * */ import c.stdio; import object; import utf; const char[] OP_NEGATE = "-"; class BaseOperand { alias BaseOperand function( BaseOperand ) unaryop; static void register_unary_operation( char[] op, unaryop unop, ClassInfo a_ci ) { } } class A : BaseOperand { int val; this( int v0 ) { val = v0; } static BaseOperand operator_negate( BaseOperand a ) { return null; } static this() { register_unary_operation( OP_NEGATE, &operator_negate, A.classinfo ); } } class B : A { this( int v0 ) { super( v0 ); } static BaseOperand operator_negate( BaseOperand a ) { return null; } static this() { register_unary_operation( OP_NEGATE, &operator_negate, A.classinfo ); // compiles if the above line is changed // register_unary_operation( OP_NEGATE, &operator_negate, B.classinfo ); } } int main( char[][] args ) { BaseOperand a; a = new A(2); return 0; }
Sep 20 2003
prev sibling next sibling parent Mike Wynn <mike l8night.co.uk> writes:
Walter wrote:
 Some long awaited features.
 
 http://www.digitalmars.com/d/changelog.html
 
 
 

Linux (RH9) dmd 0.73 multipul static function def's not detected until link time ------------- [mike localhost oper]$ ~/dmd/bin/dmd -I~/dmd/src/phobos/ test2.d gcc test2.o -o test2 -lphobos -lpthread -lm test2.o(.gnu.linkonce.t_D5test21B15operator_negateFC5test211BaseOperandZC5test 11BaseOperand+0x8): In function `_D5test21B15operator_negateFC5test211BaseOperandZC5test211BaseOperand': : multiple definition of `_D5test21B15operator_negateFC5test211BaseOperandZC5test211BaseOperand' test2.o(.gnu.linkonce.t_D5test21B15operator_negateFC5test211BaseOperandZC5test 11BaseOperand+0x0): first defined here collect2: ld returned 1 exit status --- errorlevel 256 ------------- /* * */ import c.stdio; import object; import utf; const char[] OP_NEGATE = "-"; class BaseOperand { alias BaseOperand function( BaseOperand ) unaryop; static void register_unary_operation( char[] op, unaryop unop, ClassInfo a_ci ) { } } class A : BaseOperand { int val; this( int v0 ) { val = v0; } static BaseOperand operator_negate( BaseOperand a ) { return null; } static this() { register_unary_operation( OP_NEGATE, &operator_negate, A.classinfo ); } } class B : A { this( int v0 ) { super( v0 ); } static BaseOperand operator_negate( BaseOperand a ) { return null; } static BaseOperand operator_negate( BaseOperand a ) { return null; } static this() { // register_unary_operation( OP_NEGATE, &operator_negate, A.classinfo ); register_unary_operation( OP_NEGATE, &operator_negate, B.classinfo ); } } int main( char[][] args ) { BaseOperand a,b; a = new A(2); b = new B(3); return 0; }
Sep 20 2003
prev sibling parent Mike Wynn <mike l8night.co.uk> writes:
Walter wrote:
 Some long awaited features.
 
 http://www.digitalmars.com/d/changelog.html
 
 
 

class A { }; class B : A {} for some reason within B A.classinfo is B.classinfo (rather a problem ....) --- result: ---------------- registering op[-]class[A] registering op[-]class[B] registering op[(a)]class[B] --- code: --- /* * */ import c.stdio; import object; import utf; const char[] OP_NEGATE = "-"; class BaseOperand { alias BaseOperand function( BaseOperand ) unaryop; static void register_unary_operation( char[] op, unaryop unop, ClassInfo a_ci ) { printf("registering op[%.*s]class[%.*s]\n", op, a_ci.name ); } } class A : BaseOperand { int val; this( int v0 ) { val = v0; } static BaseOperand operator_negate( BaseOperand a ) { return null; } static this() { register_unary_operation( OP_NEGATE, &operator_negate, A.classinfo ); } } class B : A { this( int v0 ) { super( v0 ); } static BaseOperand operator_negate( BaseOperand a ) { return null; } static this() { // register_unary_operation( OP_NEGATE, &operator_negate, A.classinfo ); register_unary_operation( OP_NEGATE, &operator_negate, B.classinfo ); (new B(10)).bodge_it(); } void bodge_it() { register_unary_operation( "(a)", &operator_negate, A.classinfo ); } } int main( char[][] args ) { BaseOperand a,b; a = new A(2); b = new B(3); return 0; }
Sep 20 2003