Eiffel seems to do a lot of things well that C++ doesn't.  But I'm a bigot - I can't stand that pascal-esque sytnax =)


"Charles Hixson" <charleshixsn@earthlink.net> wrote in message news:3B7D2D68.4080905@earthlink.net...
> If the C++ overloading doesn't work well, then look at other languages.
>   This is one thing that Eiffel handles fairly well (though I was at one
> point ungruntled after it refused to allow = [i.e., test for equality]
> to be overridden).
>
>

kaffiene wrote:
> 
> "Christophe de Dinechin" <descubes@earthlink.net> wrote in message news:3B7D2B88.C079FD16@earthlink.net...
> >Avoid the common pitfall of thinking: "I don't need it, therefore
> nobody
> > needs it."
> 
> That is not my point of view at all - my view is that one should avoid multiplying the number of ways in which you can achieve the same result - it makes for a code maintainence headache.  I think C++ is supremely guilty of this.
> 
> Perl is an example of a language which will provide a zillion solutions to a given problem.  It is also a language that you wouldn't want to maintain a large code base in.  I think these two facts are related.

As a counterpoint to this, I'll just point out that no one is forced to write obfuscated Perl. The Perl culture promotes it more than it should, but you _can_ write and comment Perl in such a way that it's no harder to read than, say, C. (I'll leave aside the question of whether anyone would want to maintain a large code base in C. :)

It's been said before, but bad code can be written in any language. I personally believe that _good_ code can be written in any language, as well. Even Perl.

> My point is that you have arithmetic operators for basic types. You have methods calls on objects.  This is two ways of doing things.  If you add operator overloading that's three.  With operator overloading you will still end up with some objects using method calls for add, subtract etc... and other code using operator overloading to achieve exactly the same kind of thing.

But the first way of doing things, the builtin arithmetic operators, aren't available to classes; the whole point of operator overloading is to allow the _user_ of a class the ability to use the "first way".

Philosophically, this makes more sense if your "class implementors" and "class users" are disjoint sets of people; I've never actually worked on a C++ project where this was the case. Blah blah code reuse blah blah.

-Russell B

"Russell Bornschlegel" <kaleja@estarcion.com> wrote in message news:3B7EB9F9.E9B357EF@estarcion.com...
> kaffiene wrote:
> >
> > "Christophe de Dinechin" <descubes@earthlink.net> wrote in message news:3B7D2B88.C079FD16@earthlink.net...
> > >Avoid the common pitfall of thinking: "I don't need it, therefore
> > nobody
> > > needs it."
> >
> > That is not my point of view at all - my view is that one should avoid multiplying the number of ways in which you can achieve the same
result - it
> > makes for a code maintainence headache.  I think C++ is supremely guilty
of
> > this.
> >
> > Perl is an example of a language which will provide a zillion solutions
to a
> > given problem.  It is also a language that you wouldn't want to maintain
a
> > large code base in.  I think these two facts are related.
>
> As a counterpoint to this, I'll just point out that no one is forced to write obfuscated Perl. The Perl culture promotes it more than it should, but you _can_ write and comment Perl in such a way that it's no harder to read than, say, C. (I'll leave aside the question of whether anyone would want to maintain a large code base in C. :)

Having done it, I'd have to say C is not a bad language to maintain.  It doesn't scale well, but it is at least consistent.

> It's been said before, but bad code can be written in any language. I personally believe that _good_ code can be written in any language, as well. Even Perl.

Sure.  It's just a given that when you work in Perl or C++  with more than a couple of people you will start to get code in a multitude of different styles.  OTOH, C, Scheme, Java are languages where most people can read most other people's code fairly easily.  This is a major factor in maintaining large codebases.

> > My point is that you have arithmetic operators for basic types. You have methods calls on objects.  This is two ways of doing things.  If you add operator overloading that's three.  With operator overloading you will
still
> > end up with some objects using method calls for add, subtract etc... and other code using operator overloading to achieve exactly the same kind
of
> > thing.
>
> But the first way of doing things, the builtin arithmetic operators, aren't available to classes; the whole point of operator overloading is to allow the _user_ of a class the ability to use the "first way".

Yes - as I said in my previous mail, I understand that point.   My point was that even if you do have operators on classes so users can use them like aritmetical types, you *will* get other code that refuses to user overloading.  Hence you *will* get conflicting styles.  One codebase will overload operators where it is sensible, one will overload where it is not, another will refuse to oveload even though it might make sense to do so.

 I fully understand that disallowing operator overloading prevents a user
using classes as if they were arithmetic primitives - I am saying that the
gain is scant and the cost is too severe.  As I also said previously, if we
*must* overload operators - at least do it properly and allow for arbitrary
operators and precedence so you really can represent the normal mathematical
notation for a given type (e.g. ||v|| for vector magnitude).

Cheers,

Peter.

	I'll second this.  I understand that C++ overloads are insuficant but
ugly, but this might be a case to find a better solution.  I like the
suggestion of the 'written' syntax.  It is powerful but could blow off
several toes if aimed at one's foot.  It might be nice to declare a
precedence level for new ops, that way if you define a 'dot' infix
expression you can say he has the precedence of a multiplication op.
	At the very least, I would like to see D better address matrix math
(quaternions too) and arbitrary sized numbers.

Dan

John Fletcher wrote:
> 
> Quote from the specification for D:
> 
> Operator overloading. The only practical applications for operator overloading seem to be implementing a complex floating point type, a string class, and smart pointers. D provides the first two natively, smart pointers are irrelevant in a garbage collected language.
> 
> Another quote:
> 
>  D has many features to directly support features needed by numerics
> programmers, like direct support for the complex data type and defined
> behavior for NaN's and infinities.
> 
> Comment:
> 
> For numerical computing it is convenient to define classes e.g. vectors, matrices and other entities beyond complex numbers, such as quaternions.  For this overloading of operators such as +, -, +=, etc means that top level code can be easily written and readable.
> 
> John Fletcher

kaffiene wrote:

>  I fully understand that disallowing operator overloading prevents a user
> using classes as if they were arithmetic primitives - I am saying that the
> gain is scant and the cost is too severe.

The gain is scant (if not negative) for something like "cout <<". But it is
quite serious for classes that essentially represent arithmetic objects
(matrices, vectors, complex numbers, large integers.) In that case, the
difference between A+B*C=D+E and A.Add(B.Add(C)).Eq(D.Add(E)) is really
significant. In particular in long-term maintenance.

My impression is that your own background did not expose you to such "math-oriented" environments. Then, you are right, avoiding operator overloading is probably the right thing to do.


> As I also said previously, if we
> *must* overload operators - at least do it properly and allow for arbitrary
> operators and precedence so you really can represent the normal mathematical
> notation for a given type (e.g. ||v|| for vector magnitude).

No, that is a very bad idea, and not only for technological reasons. Mathematicians invented operator precedence, not compilers (precedence is not an artifact of limited technology, it is a simplifying notation.) I don't know of any context where mathematicians read AxB+C as meaning (Ax(B+C))... But technology also indicates that this is a bad idea, because arbitrary precedences would render most expressions ambiguous.


Christophe

a wrote:

> I like the
> suggestion of the 'written' syntax.  It is powerful but could blow off
> several toes if aimed at one's foot.

Why? Could you give an example?


Christophe

Im Artikel <3B80C66E.A86462DB@earthlink.net> schrieb "Christophe de Dinechin" <descubes@earthlink.net>:

> kaffiene wrote:
> 
>>  I fully understand that disallowing operator overloading prevents a
>>  user
>> using classes as if they were arithmetic primitives - I am saying that
>> the gain is scant and the cost is too severe.
> 
> The gain is scant (if not negative) for something like "cout <<". But it
> is quite serious for classes that essentially represent arithmetic
> objects (matrices, vectors, complex numbers, large integers.) In that
> case, the difference between A+B*C=D+E and A.Add(B.Add(C)).Eq(D.Add(E))
> is really significant. In particular in long-term maintenance.
> 
> My impression is that your own background did not expose you to such "math-oriented" environments. Then, you are right, avoiding operator overloading is probably the right thing to do.
> 
> 
>> As I also said previously, if we
>> *must* overload operators - at least do it properly and allow for
>> arbitrary operators and precedence so you really can represent the
>> normal mathematical notation for a given type (e.g. ||v|| for vector
>> magnitude).
> 
> No, that is a very bad idea, and not only for technological reasons. Mathematicians invented operator precedence, not compilers (precedence is not an artifact of limited technology, it is a simplifying notation.) I don't know of any context where mathematicians read AxB+C as meaning (Ax(B+C))... But technology also indicates that this is a bad idea, because arbitrary precedences would render most expressions ambiguous.

I'm pretty sure that by "arbitrary precedence", he didn't mean that there is no precedence, or that the compiler decides what the precedence is, instead that the precedence of a given user-defined operator is user-defined, and that the user (programmer) can choose any precedence he wants for an operator that he defines.

-- 
Sheldon Simms / sheldon@semanticedge.com

"Christophe de Dinechin" <descubes@earthlink.net> wrote in message news:3B80C66E.A86462DB@earthlink.net...
> kaffiene wrote:
>
> >  I fully understand that disallowing operator overloading prevents a
user
> > using classes as if they were arithmetic primitives - I am saying that
the
> > gain is scant and the cost is too severe.
>
> The gain is scant (if not negative) for something like "cout <<". But it
is
> quite serious for classes that essentially represent arithmetic objects
> (matrices, vectors, complex numbers, large integers.) In that case, the
> difference between A+B*C=D+E and A.Add(B.Add(C)).Eq(D.Add(E)) is really
> significant. In particular in long-term maintenance.
>
> My impression is that your own background did not expose you to such "math-oriented" environments. Then, you are right, avoiding operator overloading is probably the right thing to do.

I majored in Computer Graphics.  I quite familiar with both animation for broadcast using raytracing and real time graphics using OpenGL and DirectX. I have written several raytracers.  I am about to take up a job with a broadcast graphics company.  These are "math-oriented" environments.  Your impression is wrong.

I noticed that another poster asked you to refrain from sarcasm at one point - I would also ask you to refrain from personal assumptions.  If you want to debate the technical merits of a language feature, please do so but don't do it by claiming that people with alternate opinions are ignorant.

>
> > As I also said previously, if we
> > *must* overload operators - at least do it properly and allow for
arbitrary
> > operators and precedence so you really can represent the normal
mathematical
> > notation for a given type (e.g. ||v|| for vector magnitude).
>
> No, that is a very bad idea, and not only for technological reasons. Mathematicians invented operator precedence, not compilers (precedence is
not
> an artifact of limited technology, it is a simplifying notation.) I don't
know
> of any context where mathematicians read AxB+C as meaning (Ax(B+C))... But

If you are talking about vectors, then A + B * C is the vector A added to
vector B (resulting in a vector) crossed with the vector C (resulting in a
vector).  This evaluates as (A + B) * C.  There you have a context in which
the standard arithmetic operator precedence does not hold.

> technology also indicates that this is a bad idea, because arbitrary precedences would render most expressions ambiguous.

*sigh* - please read the history of this thread.  My point is that for *new* operators that don't already exist in the language, you need to specify precedence.  For example, a Vector class could overload * for cross-product, but C++ doesn't allow overloading . (period) for dot product or ||v|| for magnitude.  If you introduce new operators you must be able to specify the precedence.  If you change the context of an operator (e.g. * in the vector example above) then the natural precendence of operators may change as well.

Peter.

kaffiene wrote:
> "Christophe de Dinechin" <descubes@earthlink.net> wrote in message
> news:3B80C66E.A86462DB@earthlink.net...
> ...vector
> example above) then the natural precendence of operators may change as well.
> 
> Peter.
> 
It seems reasonable to me that all new operators should same precedence as the dot operator.  If you want to specify a different order, you need to use parenthesis.

The idea here is that these operators are merely syntactic sugar for the functional notation.  A :+: B === A.add(B).  It is a bit easier to read.  But you don't want to encourage excessive proliferation, because if you do, then it won't be easier any more.  So you give them the same precedence as the dot operator.  (That's what they really are.)

kaffiene wrote:
> Eiffel seems to do a lot of things well that C++ doesn't.  But I'm a bigot -
> I can't stand that pascal-esque sytnax =)
> ...
> 
Eiffel is much less flexible in many ways than C++.  This is both good and bad.  The syntax doesn't matter that much if we are mining it for features to include in a new language.  Not unless we consider the syntax as one of the features that we are mining.


Actually, in the case of generics, the syntax might be worth mining. It's a lot better than the template notation, and does most of the same job.  And there's not too much wrong with the way that it declares operators (an infix operator is a function with one return value and two parameters, one implicitly specified by the class that contains it and one explicitly specified.  In the declaration the keyword infix is used preceeding the name of the operator in quotes.), but the way that Ada does it is as reasonable, and the way that C++ does it is probably more familiar.