www.digitalmars.com         C & C++   DMDScript  

D - Operator overloading, ann other idea

reply Roland <rv ronetech.com> writes:
I assume D don't have operator overloading.

too bad, how will i do with my vectors and matrixs ?

i will have to translate declaration:

Matrix operator+(Matrix& m1, Matrix& m2);

executed:

Matrix m1,m2,m3;
m3 = m1+m2;

to declaration:

Matrix plus(Matrix& m1, Matrix& m2);

executed:

Matrix m1,m2,m3;
m3 = plus(m1,m2);

not very nice..

now imagine 'plus' function could be called like this:

m3 = m1 plus m2;

better isn't it ?
is technicaly possible ?
if yes, no need for operator overloading any more.

sorry for my bad english

Regards

Roland
Aug 27 2001
next sibling parent reply "Brendan Wright" <brendan_wright hotmail.com> writes:
 now imagine 'plus' function could be called like this:

 m3 = m1 plus m2;

 better isn't it ?
 is technicaly possible ?
 if yes, no need for operator overloading any more.

I wouldn't honestly know about much about what hassles this sort of thing could introduce, but for 3D work etc it sure would make code heaps nicer and cleaner!! I hope something can be done to implement some form of operator overloading... -Brendan
Aug 30 2001
next sibling parent "Brent Schartung" <bschartung home.com> writes:
Careful.  I think we're straying dangerously close to "function objects",
one of the most obscure features of C++ (IMHO of course).  For the
uninitiated, it's a class with operator() defined; i.e. less::operator()
(char*t,int n); --I think that's right--so you can pass it to a template,
for example.  Say you define a less class that operates on two of your
classes; you'd use that less class to create a sorting template class.
Weird?

Possibly useful, definitely one of the dustier corners of the language.

Brent


 now imagine 'plus' function could be called like this:

 m3 = m1 plus m2;

 better isn't it ?
 is technicaly possible ?
 if yes, no need for operator overloading any more.


Aug 30 2001
prev sibling parent reply Dan Hursh <hursh infonet.isl.net> writes:
Brendan Wright wrote:
 
 now imagine 'plus' function could be called like this:

 m3 = m1 plus m2;

 better isn't it ?
 is technicaly possible ?
 if yes, no need for operator overloading any more.

I wouldn't honestly know about much about what hassles this sort of thing could introduce, but for 3D work etc it sure would make code heaps nicer and cleaner!! I hope something can be done to implement some form of operator overloading... -Brendan

I don't think the issue is whether or not it can be done. In C++ (the nature model to look at for another C follow up) operator overloading has caused a number of problems. The question is can it be done better. Walter has addressed some of the more common uses of operator overloading. String concatenation and (... something else that evades me at the moment). Like you, I agree that overloading is a good thing, because I like to do 3D math on occasion. Even if D did include a way of doing 3D math, I've found that in other languages that there are tradeoffs that can be made on implementation, so it is not likely that D will find the one true way that is good (or even reasonable) in all imaginable cases. (I could be wrong.) So a library should do it, but a library can only prove a procedural interface when infix is much more appropriate. That is not a reason to just cop out and pick a sorry implementation for operator overloading. We should investigate something better. I see a few problems with progress here. 1) there is one Walter, and his hands are full. 2) ops overloading does seem important to Walter and it is hardly a show stopper for D. I would hold out of a later version to review this. 3) In order to fix the problems, we would need a good formal statement of the problems. I personally am too biased in favor of ops overloading to do that. 4) formally state the desired function. For me it is a lot more string concatenation. I haven't really gotten my head around this myself, so I haven't pushed it. For me I think it boils down to wanting my own infix operations for certain types. I haven't been able to justify the need for the regular operators used on built-ins, except for in the case of writing generic functions that can operate on both built-ins and ADT's with infix ops. Since D doesn't have an answer for generic programming either, it's premature to use that argument. I like the idea for writing my own first class objects, but C++ didn't exactly get that right either, so it is hard to argue from that perspective. Since D doesn't not seem interested in wandering down the road of reflectiveness, I don't really have any good arguments. I would like to hear some of the good reasons against operator overloading. "I don't like it", "C++ did it wrong so it sucks" and "I shot myself in the foot with it" don't count. How you shot yourself is valid. Exactly how C++ got it wrong is valid too. Personal ascetics can go either way depend on the reasons. Dan
Aug 30 2001
next sibling parent "Brendan Wright" <brendan_wright hotmail.com> writes:
 I don't think the issue is whether or not it can be done.  In C++ (the
 nature model to look at for another C follow up) operator overloading
 has caused a number of problems.  The question is can it be done
 better.  Walter has addressed some of the more common uses of operator
 overloading.  String concatenation and (... something else that evades
 me at the moment).
 Like you, I agree that overloading is a good thing, because I like to
 do 3D math on occasion.  Even if D did include a way of doing 3D math,
 I've found that in other languages that there are tradeoffs that can be
 made on implementation, so it is not likely that D will find the one
 true way that is good (or even reasonable) in all imaginable cases.  (I
 could be wrong.)  So a library should do it, but a library can only
 prove a procedural interface when infix is much more appropriate.
 That is not a reason to just cop out and pick a sorry implementation
 for operator overloading.  We should investigate something better.  I
 see a few problems with progress here.
 1) there is one Walter, and his hands are full.
 2) ops overloading does seem important to Walter and
    it is hardly a show stopper for D.  I would hold out
    of a later version to review this.
 3) In order to fix the problems, we would need a good formal
    statement of the problems.  I personally am too biased in
    favor of ops overloading to do that.
 4) formally state the desired function.  For me it is a lot more
    string concatenation.  I haven't really gotten my head around
    this myself, so I haven't pushed it.

 For me I think it boils down to wanting my own infix operations for
 certain types.  I haven't been able to justify the need for the regular
 operators used on built-ins, except for in the case of writing generic
 functions that can operate on both built-ins and ADT's with infix ops.
 Since D doesn't have an answer for generic programming either, it's
 premature to use that argument.
 I like the idea for writing my own first class objects, but C++ didn't
 exactly get that right either, so it is hard to argue from that
 perspective.  Since D doesn't not seem interested in wandering down the
 road of reflectiveness, I don't really have any good arguments.

 I would like to hear some of the good reasons against operator
 overloading.  "I don't like it", "C++ did it wrong so it sucks" and "I
 shot myself in the foot with it" don't count.  How you shot yourself is
 valid.  Exactly how C++ got it wrong is valid too.  Personal ascetics
 can go either way depend on the reasons.

phew! I'm not really the expert on this one either. Less expert than you it seems anyway. Without operator overloading the language does stay nice and clean I guess, op. overloading seems to kind of hide a lot of what is really going on - possibly not a good thing when it cames to making a nice simple high-performing language. Perhaps we could start an underground movement to develop a secret pre-processor that converts op. overloading code to procedural or whatever. Because there must be a level at which you can do a simple "operator -> two input function call" conversion without getting involved in Dangerous Tricky Things. But then again, maybe I just don't understand the issues... :-) -Brendan
Aug 31 2001
prev sibling parent Russ Lewis <russ deming-os.org> writes:
Dan Hursh wrote:

         2) ops overloading does seem important to Walter and
            it is hardly a show stopper for D.  I would hold out
            of a later version to review this.

This is a good thing to remember. It is (comparatively) easy to retrofit operator overloading and templates into the language specification later. If we include some poorly designed version now, that design will have a lot of inertia (to support old code). Let's leave questionable features out for now and help Walter get the compiler out *yesterday*.
Aug 31 2001
prev sibling parent reply Charles Hixson <charleshixsn earthlink.net> writes:
Roland wrote:

 ...  now imagine 'plus' function could be called like this:

 m3 = m1 plus m2;

 better isn't it ? is technicaly possible ? if yes, no need for
 operator overloading any more.

 sorry for my bad english

 Regards

 Roland

from the rest of the language, distinguishable at a glance. The alter the order of invocation. Now in FORTH there are fancy things that appear to be operators, but actually act quite differently, but even in that foot-loose language there tends to be a clear syntactic marker used to differentiate those words from the others. (I can't remember what it is anymore. Either they begin with a period or end with a colon or some such. It's purely a convention, but it's so necessary for the language to be understood that it tends to be adhered to even though anyone can define any word of any kind that they choose. Or even redefined words standardly defined in the system.) I prefer something simple, like :+: or :plus:, but note the boundary markers. This would make them distinguishable at a glance. And I think that this would be important. These are actually just method calls with sugar, i.e., a :+: b == a.:+:(b), there shouldn't be much compiler overhead, and I feel that they should be a overloadable as any other method. But I am not arguing that the standard operators should be overloadable. They may have special compiler optimizations, etc. But I think that user definable operators are desireable, and that they should be overloadable. But for the sake of intelligibility, please keep their syntax class easily recognizable.
Sep 05 2001
parent reply Roland <rv ronetech.com> writes:
Charles Hixson a écrit :

 Roland wrote:

  > ...  now imagine 'plus' function could be called like this:
  >
  > m3 = m1 plus m2;
  >
  > better isn't it ? is technicaly possible ? if yes, no need for
  > operator overloading any more.
  >
  > sorry for my bad english
  >
  > Regards
  >
  > Roland
  >
 eeeep!  Not very nice at all.  Operators should be clearly demarkated
 from the rest of the language, distinguishable at a glance.  The alter
 the order of invocation.  Now in FORTH there are fancy things that
 appear to be operators, but actually act quite differently, but even in
 that foot-loose language there tends to be a clear syntactic marker used
 to differentiate those words from the others.  (I can't remember what it
 is anymore.  Either they begin with a period or end with a colon or some
 such.  It's purely a convention, but it's so necessary for the language
 to be understood that it tends to be adhered to even though anyone can
 define any word of any kind that they choose.  Or even redefined words
 standardly defined in the system.)

 I prefer something simple, like :+: or :plus:, but note the boundary
 markers.  This would make them distinguishable at a glance.  And I think
 that this would be important.  These are actually just method calls with
 sugar, i.e., a :+: b == a.:+:(b), there shouldn't be much compiler
 overhead, and I feel that they should be a overloadable as any other
 method.  But I am not arguing that the standard operators should be
 overloadable.  They may have special compiler optimizations, etc.  But I
 think that user definable operators are desireable, and that they should
 be overloadable.  But for the sake of intelligibility, please keep their
 syntax class easily recognizable.

for me 'm3 = m1 plus m2;' is recognizable enough. the main arguments against operator overloading i note are: - it hides computation time too much, - you can't make a find on '+' word as it will find you overloaded operator and normal one as well. when i read 'm3 = m1 plus m2' i know: - m1 or m2 or both are classes, - 'plus' is a function i wrote and i can make a find on its name. personally don't need any more. i think Brent Schartung argument:
Careful.  I think we're straying dangerously close to "function objects",
one of the most obscure features of C++

Roland
Sep 05 2001
parent reply Russ Lewis <russ deming-os.org> writes:
Roland wrote:

 for me 'm3 = m1 plus m2;' is recognizable enough.

 the main arguments against operator overloading i note are:
 - it hides computation time too much,
 - you can't make a find on '+' word as it will find you overloaded operator
 and normal one as well.

 when i read 'm3 = m1 plus m2' i know:
 - m1 or m2 or both are classes,
 - 'plus' is a function i wrote and i can make a find on its name.
 personally don't need any more.

 i think Brent Schartung argument:
Careful.  I think we're straying dangerously close to "function objects",
one of the most obscure features of C++


Using infix words is nice in your example, but I think that it will tend to suffer from 'PERL syndrome' (so much syntax flexibility that the code is nearly impossible to read). This might also be legal: var1 each word in this line is another operator but which ones do what var2; Which would also be legal. I really like operator overloading in C++, but I understand that it may be too complex or unnecessary for most applications. What can we do about this? I have a ponder...but it's OT enough I'm going to start a new thread about it. Look for 'externally processed blocks'.
Sep 05 2001
parent Roland <rv ronetech.com> writes:
Russ Lewis a écrit :

 Roland wrote:

 for me 'm3 = m1 plus m2;' is recognizable enough.

suffer from 'PERL syndrome' (so much syntax flexibility that the code is nearly impossible to read). This might also be legal: var1 each word in this line is another operator but which ones do what var2; Which would also be legal.

i tried to translate var1 each word in this line is another operator but which ones do what var2; replace 'each' by '+', 'word' by '-', 'in' by '/' ..'what' by '*', you have something like var1 +-/..* var2; not legal in C++ an other way is to translate like this (all one argument operator exept 'each'): each(var1, word(in(this(line(is(another(operator(but(which(ones(do(what(var2))))))))))))); witch is less clear than var1 each word in this line is another operator but which ones do what var2;
 Look for 'externally processed blocks'.

i will Roland
Sep 06 2001