Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > Re: Operator overloading a mistake??

Reply
Thread Tools

Re: Operator overloading a mistake??

 
 
David White
Guest
Posts: n/a
 
      07-21-2003
Paul Fame <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Hello World
>
> In my University course teaching Java, my lecturer just claimed,
> amongst other atrocities, that operator overloading in C++ was a
> mistake, and that Java's lack of operator overloading was a "big step
> forward".
>
> Can anyone else provide counter-arguments to this, to prove I am still
> sane?


You have presented no arguments to counter, only assertions.

DW



 
Reply With Quote
 
 
 
 
Paul Fame
Guest
Posts: n/a
 
      07-21-2003
Hi,

>> In my University course teaching Java, my lecturer just claimed,
>> amongst other atrocities, that operator overloading in C++ was a
>> mistake, and that Java's lack of operator overloading was a "big step
>> forward".
>>
>> Can anyone else provide counter-arguments to this, to prove I am still
>> sane?

>
>You have presented no arguments to counter, only assertions.


Well, his argument, as far as I see, was that operator overloading is
"too powerful for it's own good". He also doesn't like templates, and
thinks Java's Strings are better than char*'s (apparently not knowing
that C++ standard library exists).

Anyway, I mostly dislike Java, think it's shocking it became so
popular, and still prefer syntax

v[x][y]

compared to

(Integer)((Vector)(v.elementAt(x)).elementAt(y)),i ntValue()

- Paul

 
Reply With Quote
 
 
 
 
Peter van Merkerk
Guest
Posts: n/a
 
      07-21-2003
"Paul Fame" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Hi,
>
> >> In my University course teaching Java, my lecturer just claimed,
> >> amongst other atrocities, that operator overloading in C++ was a
> >> mistake, and that Java's lack of operator overloading was a "big

step
> >> forward".
> >>
> >> Can anyone else provide counter-arguments to this, to prove I am

still
> >> sane?

> >
> >You have presented no arguments to counter, only assertions.

>
> Well, his argument, as far as I see, was that operator overloading is
> "too powerful for it's own good".


Like just about any other language feature, they can be abused. Operator
overloading is just syntactic sugar, you can do without, but like you
demonstrated it can make things more readable when applied
appropriately.

> He also doesn't like templates, and


If templates are really that bad, why does he think that there are
serious efforts to add them to the Java language (just search for "Java
Generics"). Does he promote excessive casting as a good thing or does he
suggest to write a container again and again for every type.

> thinks Java's Strings are better than char*'s (apparently not knowing
> that C++ standard library exists).


So his judgements are based on ignorance. If I were I would I ignore his
opinions, and form your own opininions based on facts rather than
misconceptions.

> Anyway, I mostly dislike Java, think it's shocking it became so
> popular, and still prefer syntax
>
> v[x][y]
>
> compared to
>
> (Integer)((Vector)(v.elementAt(x)).elementAt(y)),i ntValue()


Like C++, Java has its strengths and its weaknesses. The context
determines which language is preferable.

--
Peter van Merkerk
peter.van.merkerk(at)dse.nl


 
Reply With Quote
 
Cy Edmunds
Guest
Posts: n/a
 
      07-21-2003
<snip>

> Like just about any other language feature, they can be abused. Operator
> overloading is just syntactic sugar,


<snip>

No, the comma operator is syntactic sugar (although a rather bitter form of
sugar to be sure). Huge portions of the C++ Standard Library depend
critically on operator overloading.

--
Cy
http://home.rochester.rr.com/cyhome/


 
Reply With Quote
 
cody
Guest
Posts: n/a
 
      07-21-2003
> No, the comma operator is syntactic sugar (although a rather bitter form
of
> sugar to be sure). Huge portions of the C++ Standard Library depend
> critically on operator overloading.



in java there is the comma operator too, but it is allowed in for-loops
only.

in c,c++ it seems it was more important to make things more consistent. "if
this operator is neccessary in for-loops we should allow it everywhere, to
make the compiler not unneccesary complicated"

--
cody

[Freeware, Games and Humor]
www.deutronium.de.vu || www.deutronium.tk


 
Reply With Quote
 
Victor Bazarov
Guest
Posts: n/a
 
      07-21-2003
"cody" <(E-Mail Removed)> wrote...
> > No, the comma operator is syntactic sugar (although a rather bitter form

> of
> > sugar to be sure). Huge portions of the C++ Standard Library depend
> > critically on operator overloading.

>
>
> in java there is the comma operator too, but it is allowed in for-loops
> only.
>
> in c,c++ it seems it was more important to make things more consistent.

"if
> this operator is neccessary in for-loops we should allow it everywhere, to
> make the compiler not unneccesary complicated"


I don't think that was the motivation behind allowing to overload
operator comma. Basically, the language followed this pattern:
allow it, unless there is a compelling reason not to. [For example,
allowing overloading operator dot would interfere with the ability
to call a member.]

Victor


 
Reply With Quote
 
Peter van Merkerk
Guest
Posts: n/a
 
      07-21-2003
> > Like just about any other language feature, they can be abused. Operator
> > overloading is just syntactic sugar,

> <snip>
> No, the comma operator is syntactic sugar (although a rather bitter form

of
> sugar to be sure). Huge portions of the C++ Standard Library depend
> critically on operator overloading.


So do you suggest there would be no standard library without operator
overloading or just that it would look differently? My guess would be the
latter. No doubt code using the standard library would look a lot uglier if
the language didn't support operator overloading. However I cannot think of
an example illustrating functionality that would be impossible to implement
without operator overloading, can you?

The way I see it, operator overloading allows certain functions to be called
in a much more natural way, but in the end they are still just functions.
Feel free to point out what is wrong with this picture.

--
Peter van Merkerk
peter.van.merkerk(at)dse.nl




 
Reply With Quote
 
Victor Bazarov
Guest
Posts: n/a
 
      07-21-2003
"Peter van Merkerk" <(E-Mail Removed)> wrote...
> > > Like just about any other language feature, they can be abused.

Operator
> > > overloading is just syntactic sugar,

> > <snip>
> > No, the comma operator is syntactic sugar (although a rather bitter form

> of
> > sugar to be sure). Huge portions of the C++ Standard Library depend
> > critically on operator overloading.

>
> So do you suggest there would be no standard library without operator
> overloading or just that it would look differently? My guess would be the
> latter. No doubt code using the standard library would look a lot uglier

if
> the language didn't support operator overloading. However I cannot think

of
> an example illustrating functionality that would be impossible to

implement
> without operator overloading, can you?
>
> The way I see it, operator overloading allows certain functions to be

called
> in a much more natural way, but in the end they are still just functions.
> Feel free to point out what is wrong with this picture.


The biggest ugliness is precedence and associativity. We take it
for granted that a + b * c is executed in a certain order (first
the multiplication, then addition). Imagine that had there been
no operator overloading we'd have to make sure that the order is
the right one. It's much less obvious with functions, IMHO.

And how would you implement the -> operator for smart pointers
and iterators without overloading -> or * ?

Yes, the library would still exist and would definitely look
different. For all built-in types there would be functions like
'plus', 'times', 'unary minus', etc. implemented. Inline.
Probably templated. Yech!

As to the what's wrong is simple: compiler optimisation. Since
there would have to be functions 'plus' and 'times' in the library
just to support the algorithms, the compiler would be precluded
from optimising those because there is a sequence point before
a function call after evaluation of all arguments. Expression
A.plus(B.times(C)) would have two extra sequence points compared
to expression A + B * C. Yes, for UDT it's not different. But
for built-ins it is.

Victor


 
Reply With Quote
 
Cy Edmunds
Guest
Posts: n/a
 
      07-22-2003
"Peter van Merkerk" <(E-Mail Removed)> wrote in message
news:bfhnfu$eo35m$(E-Mail Removed)-berlin.de...
> > > Like just about any other language feature, they can be abused.

Operator
> > > overloading is just syntactic sugar,

> > <snip>
> > No, the comma operator is syntactic sugar (although a rather bitter form

> of
> > sugar to be sure). Huge portions of the C++ Standard Library depend
> > critically on operator overloading.

>
> So do you suggest there would be no standard library without operator
> overloading or just that it would look differently? My guess would be the
> latter. No doubt code using the standard library would look a lot uglier

if
> the language didn't support operator overloading. However I cannot think

of
> an example illustrating functionality that would be impossible to

implement
> without operator overloading, can you?
>
> The way I see it, operator overloading allows certain functions to be

called
> in a much more natural way, but in the end they are still just functions.
> Feel free to point out what is wrong with this picture.
>
> --
> Peter van Merkerk
> peter.van.merkerk(at)dse.nl
>
>



Well, for starters the entire iostream library is based on operator
overloading.

--
Cy
http://home.rochester.rr.com/cyhome/


 
Reply With Quote
 
Peter van Merkerk
Guest
Posts: n/a
 
      07-22-2003
> > So do you suggest there would be no standard library without
operator
> > overloading or just that it would look differently? My guess would

be the
> > latter. No doubt code using the standard library would look a lot

uglier
> if
> > the language didn't support operator overloading. However I cannot

think
> of
> > an example illustrating functionality that would be impossible to

> implement
> > without operator overloading, can you?
> >
> > The way I see it, operator overloading allows certain functions to

be
> called
> > in a much more natural way, but in the end they are still just

functions.
> > Feel free to point out what is wrong with this picture.

>
> The biggest ugliness is precedence and associativity. We take it
> for granted that a + b * c is executed in a certain order (first
> the multiplication, then addition). Imagine that had there been
> no operator overloading we'd have to make sure that the order is
> the right one. It's much less obvious with functions, IMHO.


No disagreement there.

> And how would you implement the -> operator for smart pointers
> and iterators without overloading -> or * ?


I'm not saying that operator overloading is useless or bad, quite the
contrary actually. Without operator overloading the usage of smart
pointers would be a lot less transparent, but not impossible.

> Yes, the library would still exist and would definitely look
> different. For all built-in types there would be functions like
> 'plus', 'times', 'unary minus', etc. implemented. Inline.
> Probably templated. Yech!


I didn't say it was going to be pretty, just that it possible.

> As to the what's wrong is simple: compiler optimisation. Since
> there would have to be functions 'plus' and 'times' in the library
> just to support the algorithms, the compiler would be precluded
> from optimising those because there is a sequence point before
> a function call after evaluation of all arguments. Expression
> A.plus(B.times(C)) would have two extra sequence points compared
> to expression A + B * C. Yes, for UDT it's not different. But
> for built-ins it is.


That might have been a reason to add operator overloading to C++ (and
not to Java where the order of evalution is guaranteed). I still think
however that the biggest advantage and probably the most important
reason to include operator overloading in the language is the clearer
and more natural syntax.
--
Peter van Merkerk
peter.van.merkerk(at)dse.nl




 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
overloading operator->*() and operator->() gob00st@googlemail.com C++ 2 02-21-2009 04:26 AM
overloading operator->*() and operator->() gob00st@googlemail.com C++ 11 02-20-2009 08:52 PM
user defined conversion operator or operator overloading? hurcan solter C++ 3 08-29-2007 07:39 PM
Why is overloading operator. (member operator) forbidden? dascandy@gmail.com C++ 11 05-16-2007 07:54 PM
Operator overloading on "default" operator John Smith C++ 2 10-06-2004 10:22 AM



Advertisments