Russ Lewis writes:
> In a well controlled, well designed situation, programming convenience
OFTEN
> LEADS TO CODE RELIABILITY.  When the code is easy to write and
> read, and most
> importantly WHEN IT DOES WHAT IT SEEMS LIKE IT DOES, the two
> are one and the same.

I agree.  But well controlled, well designed situations <rarely> occur.  So operator overloading <rarely> improves code reliability and clarity.

Operator overloading is inferior in every respect to the ability to provide new operators.

Providing new operators provides all of the benefits, and allows the programmer to avoid all of the pitfalls.

I wouild make one exception. Equality.  Equality can at all times be taken to be byte by byte identical. for comparison, and byte by byte assignment for assignment.

OddesE <OddesE_XYZ@hotmail.com> wrote in message
> I wouldn't say that code reliability is that much at stake with operator overloading. Consider the next piece of code:
>
> MyClass result.Assign(MyClass::.Add (Var1, MyClass::Multiply (Var1,
Var3)));
>
> Then consider the same code using operator overloading:
>
> MyClass result = Var1 + Var1 * Var3;

Consider this piece of code

define op var1 .* var3 = MyClass::Multiply(Var1,Var3)
define op var1. .+ var3 = MyClass::Add(Var1.Var3)

MyClass::result =  Var1 .+ Var1 .* Var3

I fail to see your complaint Mr OdessE.  Perhaps you can explain it to me.



OdessE writes:
> Now I doubt that there will be many people telling me the first snippet is more readable than the second.

Now I dount that there will be many people telling me that

MyClass::result =  Var1 .+ Var1 .* Var3

is any less readable than

MyClass result = Var1 + Var1 * Var3;

OdessE writes:
> After I wrote
> it, I had to examine it 4 times to make sure I had it correct,
> with all the braces and the order of the arguments.

I had no such burden.


> > The problem with operator overloading is that it can be highly
confusing.
> > What Isn't highly confusing however, and what does provide the same
> benefit
> > is providing the ability to create your own operators.

OdessE writes:
> Mmmm.... So you don't understand what A + B or C * D
> means, but you do understand all of the very complex
> operators that exist in math today, as well as the ones that
> I personally come up with?

Clearly no one can, since the meaning of + and * are dependent on the types of A, B, C and D.

You may claim to know the meaning, but if so,  you are lying to yourself.



OdessE writes:
> if (! A.Cmp (B))
>
> or
>
> if (A == B)

It depends on what A and B are.and what you are trying to do.  Perhaps A and B are objects, the == syntax can have three equally appropriate meanigns.  A is numerically identical to B,  A is functionally identical to B, A and B are the same object.

With one equal sign, how do you intend to distingish between these three poetntial meanings?  How do you intend to implement more than one of them at a time?

I await your response.


> > Operator Overloading is very, very bad news.

OdessE writes:
> There are some very bad things that *can* be done with operator overloading, but there are also some very good.

The bad outweighs to good.  <period>

"D" <s_nudds@hotmail.com> wrote in message news:a3nmm4$2b86$1@digitaldaemon.com...

> Now I dount that there will be many people telling me that
>
> MyClass::result =  Var1 .+ Var1 .* Var3
>
> is any less readable than
>
> MyClass result = Var1 + Var1 * Var3;

I do. If I use your library, I'd expect + to add vectors.
I would have never think of .+, before reading the docs to the
point where it's mentioned.

> "D" <s_nudds@hotmail.com> wrote in message

> > Now I dount that there will be many people telling me that
> >
> > MyClass::result =  Var1 .+ Var1 .* Var3
> >
> > is any less readable than
> >
> > MyClass result = Var1 + Var1 * Var3;

Pavel Minayev <evilone@omen.ru> wrote in message news:a3o1gc$2fji$1@digitaldaemon.com...
> I do. If I use your library, I'd expect + to add vectors.
> I would have never think of .+, before reading the docs to the
> point where it's mentioned.

Yet you see .+ being applied to a variable, perhaps a vector, perhaps not.

This visual cue tells you that you had better pay careful attention to that statement because it is using user defined operators and probably aggregate variables.

With

MyClass result = Var1 + Var1 * Var3;

on the other hand there are no visual cues and the expression could very well be a simple one that does not need further investigation.

Visual cues are a good thing.  They aid us in avoiding error.

"D" <s_nudds@hotmail.com> ha scritto nel messaggio news:a3o85r$2jck$1@digitaldaemon.com...
>
> Yet you see .+ being applied to a variable, perhaps a vector, perhaps not.
>
> This visual cue tells you that you had better pay careful attention to
that
> statement because it is using user defined operators and probably
aggregate
> variables.
>
> With
>
> MyClass result = Var1 + Var1 * Var3;
>
> on the other hand there are no visual cues and the expression could very well be a simple one that does not need further investigation.
>
> Visual cues are a good thing.  They aid us in avoiding error.

I must admit you have a point here, but that little dot can be easily hidden
inside a big expression. Any other idea?
I think it's useful to know if I'm calling an overloaded operator or not,
but adding the littlest dot definitely isn't the solution.

Ciao

"D" <s_nudds@hotmail.com> wrote in message news:a3nl7n$2ao0$1@digitaldaemon.com...
>
> Sean L. Palmer writes:
> > Your first paragraph shows you to be closed minded.  By that argument, pointers must be removed from the language, as well as anything that can
> be
> > remotely dangerous such as typecasting.  By the time you're done you
won't
> > have much of a language left.
>
>   Pointers have their place because they improve efficiency.  Operator
> overloading provides no such advantage.  It is simply a convenience
feature
> for a minute number of situations that in most situations is abused
thereby
> reducing code quality and maintainance.
>
>   Defining new operators however is a different story.  New operators can
> provide the same utility as existing ones without the associated problems
of
> precidence and predefined meaning that limits the usefulness of the C/C++ implemntation.
>
>   Members of the C religion like to argue that their God is the only God.
> When they accuse me of having a closed mind, I laugh.
>
>
> Sean L. Palmer writes:
> > I bet you have problems figuring out what happens when you add a char to
a
> > float and then add the result to an int.
>
> I do, because in crap languages like C/C++ the sign of char is not defined in the standard,  the Char may be signed or unsigned and which is left up
to
> the compiler.
>
> What is also wrong with C/C++ is that char is considered numeric at all. That is the height of stupidity.  Rather characters should be relegated to characters, an only available as numbers if they are explicity cast as
such.
>
> Members of the C faith will whine.  Let them whine.
>
>
> Sean L. Palmer writes:
> > I'm not in favor of stripping away language utility to make up for the deficiencies of the lowest common denominator programmer.
>
> Clearly you do favour such a thing, since if you did not then youi would
be
> programmig in assembler where you can create what you wish, when you wish. With assembler you have absolute freedom.
>
> So by selecting any HLL or MLL you have already decided to make a
tradeoff.
>
> Your whine therefore has no significance, other than to show a reluctance
to
> accept reason.
>
>
> Sean L. Palmer writes:
> >  At least people can be trained proper coding
> > technique.  But it's difficult to add functionality to your compiler in
> most
> > cases (GCC at least allows it, but still not easy).  So removing functionality is just going to cause language holes to exist that will
> give
> > people great big excuses to use a language that has all the
functionality
> > they need, even if that language is C++ and allows you to shoot yourself
> in
> > the foot.
>
> No.  Language holes exist as a result of features that can not be
completely
> implemented due to compiler constraints, or compile time requirements.
>
> Just as not every mathematical function has an easily computable inverse, not every design characteristic of a language can be fully implemented in concept across the language.  Those areas where the implementation becomes difficult are the areas where there are holes in the language.
>
> One of the holes in the C language is the foolish method chosen to
implement
> autoincrement, and the restrictions placed on the use of the operation in complex  equations.  Rather than have the compiler spend the time to properly implement the function, the morons who invented the C language
(may
> they eternally burn in hell), decided to place the onus on the programmer
to
> use the feature "properly".  I.E. to use the feature in a manner in which the compiler doesn't fail.
>
> Sean L. Palmer writes:
>  > The main problem with operator overloading is that people don't bother
to
> > look up the declaration of the variables they're dealing with.
>
> Wrong.  The main problem with operator overloading is that the given meanings of the exiting operators do not lend themselves to the operations that typically need to be performed.  This results in programmers doing things like using the division operator to compare strings, and stupid things like that.
>
>
>
> Sean L. Palmer writes:
> > In any case, I expect people on my team to verify that their code works before checking it in.  If you get operator overloading wrong, you'll
> notice
> > as soon as you run it because the behavior won't be what you expected.
> (try
> > to assign the result of a dot product to a vector, or the result of a
> cross
> > product to a float, and you'll get a type mismatch of some kind at
compile
> > time)
>
> There are two kinds of product for vectors.  Which of the two existing operators are you going to use to specify them?
>

The one you use most. The other you use a named function for. Without operator overloading you will always have to use a named function to describe mathematical operations.


--
Stijn
OddesE_XYZ@hotmail.com
http://OddesE.cjb.net
__________________________________________
Remove _XYZ from my address when replying by mail

Roberto Mariottini <rmariottini@lycosmail.com> wrote in message news:a3okd3$2oil$1@digitaldaemon.com...

> I must admit you have a point here, but that little dot can be easily
hidden
> inside a big expression. Any other idea?
> I think it's useful to know if I'm calling an overloaded operator or not,
> but adding the littlest dot definitely isn't the solution.

I toyed with the idea of bracketing them <+> <-> etc..

"D" <s_nudds@hotmail.com> wrote in message news:a3nmm4$2b86$1@digitaldaemon.com...
>
> OddesE <OddesE_XYZ@hotmail.com> wrote in message
> > I wouldn't say that code reliability is that much at stake with operator overloading. Consider the next piece of code:
> >
> > MyClass result.Assign(MyClass::.Add (Var1, MyClass::Multiply (Var1,
> Var3)));
> >
> > Then consider the same code using operator overloading:
> >
> > MyClass result = Var1 + Var1 * Var3;
>
> Consider this piece of code
>
> define op var1 .* var3 = MyClass::Multiply(Var1,Var3)
> define op var1. .+ var3 = MyClass::Add(Var1.Var3)
>
> MyClass::result =  Var1 .+ Var1 .* Var3
>
> I fail to see your complaint Mr OdessE.  Perhaps you can explain it to me.
>

Consider this pieces of code:

define op var1 ** var3 = MyClass::Multiply(Var1,Var3)
define op var1. *+ var3 = MyClass::Add(Var1.Var3)
define op var1 #* var3 = MyClass::Multiply(Var1,Var3)
define op var1. #+ var3 = MyClass::Add(Var1.Var3)
define op var1 $* var3 = MyClass::Multiply(Var1,Var3)
define op var1. $+ var3 = MyClass::Add(Var1.Var3)
define op var1 @* var3 = MyClass::Multiply(Var1,Var3)
define op var1. @+ var3 = MyClass::Add(Var1.Var3)
define op var1 &* var3 = MyClass::Multiply(Var1,Var3)
define op var1. &+ var3 = MyClass::Add(Var1.Var3)

MyClass::result =  Var1 *+ Var1 ** Var3
MyClass::result =  Var1 #+ Var1 #* Var3
MyClass::result =  Var1 $+ Var1 $* Var3
MyClass::result =  Var1 @+ Var1 @* Var3
MyClass::result =  Var1 &+ Var1 &* Var3

Now you tell me that you don't see any problems in this?
How am I supposed to know what strange character
sequence a programmer selected to convey a plus operation?
You could use some kind of standard, but what is the
point? Why do you think people can easily abuse normal
operator overloading, but replacing the normal operator
sign that everyone knows with some weird sign nobody
knows wil leviate this problem?

Who keeps me from doing this:

define op var1 .* var3 = MyClass::Add (Var1,Var3)
define op var1. .+ var3 = MyClass::Multiply (Var1.Var3)

MyClass::result =  Var1 .+ Var1 .* Var3

Now do you still understand this example?
I really don't see any big differences in this.
Your solution does not prevent the abuse you keep talking
about. Ok, so maybe if people see .= they will look it up
in the docs. Or maybe they just assume it is assign. At least
with the normal = there is a defined meaning what the
operator *should* do. Now it could be anything. I think the
code just got much _less_ self-documenting!


>
>
> OdessE writes:
> > Now I doubt that there will be many people telling me the first snippet is more readable than the second.
>
> Now I dount that there will be many people telling me that
>
> MyClass::result =  Var1 .+ Var1 .* Var3
>
> is any less readable than
>
> MyClass result = Var1 + Var1 * Var3;
>

I am telling it. I never saw an operator .+ before. Not in
Delphi/Java/C/C++, nor in math. How am I supposed to
know what it means?  I could *assume* it means plus,
but I wouldn't know it. At least with normal + I know
what it normally means (in math or other languages).


> OdessE writes:
> > After I wrote
> > it, I had to examine it 4 times to make sure I had it correct,
> > with all the braces and the order of the arguments.
>
> I had no such burden.
>

Good for you, but you are contradicting yourself with this
cowboy-coder comment. So if you know what it means
than it is not a problem eh?
You still didn't say that

MyClass result.Assign(MyClass::.Add (Var1, MyClass::Multiply (Var1, Var3)));

is more readable than

MyClass result = Var1 + Var1 * Var3;

probably because it just isn't.


> > > The problem with operator overloading is that it can be highly
> confusing.
> > > What Isn't highly confusing however, and what does provide the same
> > benefit
> > > is providing the ability to create your own operators.
>
> OdessE writes:
> > Mmmm.... So you don't understand what A + B or C * D
> > means, but you do understand all of the very complex
> > operators that exist in math today, as well as the ones that
> > I personally come up with?
>
> Clearly no one can, since the meaning of + and * are dependent on the
types
> of A, B, C and D.
>

And clearly no one can now the meaning of .+ and .*
At least with normal operators I know what they usually do and
have a reference in math or other languages to draw experience on.


> You may claim to know the meaning, but if so,  you are lying to yourself.
>

If I write a function CString MyClass::ToString(), are you going to
trust me that it will convert MyClass to a string? If you don't, good
luck spending the rest of your life trying to read in the (sometimes
nonexistent) documentation of code trying to figure out what bloody
obvious functions do.
If you do, how can you be sure I didn't write the function in such a
way that it formats your hard-drive? The fact is you can't. I could
even have written misleading documentation that tells you that my
function converts MyClass to a CString, when in fact it just wipes
your disc. Are you really saying you are manually checking the code
of every third party function you ever use?  Functions should have
descriptive names and they should do what you expect of them.
If they don't, the code is effectively broken.
Everyone knows what string1 = string2 + string3 is supposed to
do. If you don't you can always still look it up. At least with
normal operators there is a common base of experience people
can draw from.


>
>
> OdessE writes:
> > if (! A.Cmp (B))
> >
> > or
> >
> > if (A == B)
>
> It depends on what A and B are.and what you are trying to do.  Perhaps A
and
> B are objects, the == syntax can have three equally appropriate meanigns.
A
> is numerically identical to B,  A is functionally identical to B, A and B are the same object.
>
> With one equal sign, how do you intend to distingish between these three poetntial meanings?  How do you intend to implement more than one of them
at
> a time?
>
> I await your response.
>

I don't really see how Cmp solves these issues better then operator
overloading.
And if you compare two numbers to see if they are equal, do you try to find
out if the are the same instance of an int? Draw from experience.

int A = 10;
int B = 10;
int C = 0;

if (A == B)
   C = A;
B = 5;

What value does C have?


>
> > > Operator Overloading is very, very bad news.
>
> OdessE writes:
> > There are some very bad things that *can* be done with operator overloading, but there are also some very good.
>
> The bad outweighs to good.  <period>
>

No it doesn't. Period.


--
Stijn
OddesE_XYZ@hotmail.com
http://OddesE.cjb.net
__________________________________________
Remove _XYZ from my address when replying by mail

> I wouild make one exception. Equality.  Equality can at all times be taken to be byte by byte identical. for comparison, and byte by byte assignment for assignment.

According to IEEE 754,
-0.0 == +0.0, but have different binary representation.

Serge K wrote:

>>I wouild make one exception. Equality.  Equality can at all times be taken
>>to be byte by byte identical. for comparison, and byte by byte assignment
>>for assignment.
>>
> 
> According to IEEE 754,
> -0.0 == +0.0, but have different binary representation.


Just an anecdote, but I've run into a compiler that evaluated
(-0.0 == +0.0) as false. I discovered this while porting code
from a compiler that evaluated it as true. Let me tell you,
that was a fun one, especially since the the only manifestation
was "some of the rotating objects in the world rotate around
the wrong axis."

-Russell B