R
Richard
jacob navia said:
ok,
What does
i=j+k;
mean?
And no I wont show you the code which overloads "=" and "+" for the
types in question - that code is 50 pages away in the printout.
See?
ok,
What does
i=j+k;
mean?
And no I wont show you the code which overloads "=" and "+" for the
types in question - that code is 50 pages away in the printout.
See?
U
user923005
You are no more in the dark here than:
what does
i=foobar(j,k);
mean?
"Stupid is as stupid does." -- Forest Gump.
Lesson:
Don't hire Forest Gump as your programmer. Lieutenant Dan is a much
better bet.
R
Richard
user923005 said:
Only if I was fool enough to call a function foobar. If you dont think
its easier to see a function call and realising what it does from a
meaningful name than it is for "+" and "=" then you're quite a unique
person. Me? I prefer a function name. With tags navigation and possibly
context sensitive help. OK, we're talking more C++ in general but, well,
I rarely saw operator overloading used responsibly past the usual text
book examples.
I feel you make my point for me there. Not all programmers are "the
best" and the larger the development team, and maintenance team the more
likely things are to be abused.
U
user923005
OK, then:
i=add_together_returning_integer(j,k);
Surprise, surprise. This function formats your disk drive. Looks
like C is a stupid langugage then, because you can make mistakes with
it.
Anything can be abused. Knives can stab people, so don't make
knives. Cars can run over people so don't make cars. Bricks can
break a window so don't make bricks.
When we use things properly, things tend to come out better. When we
work with whinging twits who do stupid things with sensible tools we
run into trouble. So work with smart people. And if you are working
with someone stupid, they are just exactly as likely to do something
dumb with:
i=add_together_returning_integer(j,k);
as they are with:
i = j + k;
And do you know why? Because they're *stupid*.
R
Richard
user923005 said:
Oh for goodness sake. Get a clue. We are not discussing anything
subversive here. Its simply about reading reasonable code.
In true c.l.c fashion you spend time explaining the obvious. of course
things can be abused.
That is not the issue at point.
The issue at point is that when READING code I know what is a lot
clearer to the maintenance team.
Really? Thanks for that.
No. I think you just have too high an opinion of yourself.
S
Serve Lau
user923005 said:
Thats the point. It doesnt because C++ has operator overloading which make
it possible to add arithmetic types to the library and you dont have to
introduce language features. So I'm not sure if MS will add complex numbers
(among others) to their C compiler when they add the overlapping C/C++
features to C++. But at least all of the library functions introduced in C99
will become available to the C compiler too.
Even all float versions of the math functions like sqrtf are added to C++
while they dont need it because of function overloading. So there is hope
S
Serve Lau
Richard said:
You're making the code unclear on purpose. I would assume that calling the
variables i,j,k means that they are arithmetic types and local to a
function. If they are not I dont think operator overloading is the problem
here. Having the declaration of variables i,j,k 50 pages away is just asking
for trouble.
I
Ian Collins
Richard said:
So "add_together_returning_integer" is clearer than "+"?
J
James Kuyper
Richard wrote:
....
To be fair, you have to compare your example with the code that would
have to be used in a context where operator overloading is unavailable
(like C).
What does
assign(&i, add(j,k));
mean?
And no, I won't show you the code that implements assign() and add() for
the types in question - that code is 50 pages away in the printout.
....
To be fair, you have to compare your example with the code that would
have to be used in a context where operator overloading is unavailable
(like C).
What does
assign(&i, add(j,k));
mean?
And no, I won't show you the code that implements assign() and add() for
the types in question - that code is 50 pages away in the printout.
B
Ben Bacarisse
James Kuyper said:
Yes, that is the fair comparison and it does highlight a difference.
To fully understand the latter I must go find those functions (or
possibly just the documentation for them). To understand the former,
I must first find the declarations of the variables and /then/ find the
definitions (or documentation) for + and = for that type. Operator
(and function) overloading adds a level of indirection to the process
of comprehension.
It seems to me undeniable that the execution model of overloaded code
is (slightly) more complex, but it is not obvious that that results in
code that is, inevitably, harder to maintain. Programs that use
overloading well can be clear and easy to maintain because of the
expressiveness of the mechanism. (I confess this is no more than a
guess.)
On a non-technical level, some language features seem more prone to
beginner abuse than others, and overloading (specifically operator
overloading) seems to be one of them.
W
Walter Roberson
Ian Collins said:
Like the old joke about object oriented cobol being named
"Add one to COBOL returning COBOL" ?
J
James Kuyper
Ben said:
While operator overloading and the overloading of functions in general
are, in principle, separable concepts, it seems to me that they are a
natural combination. When both are present (as is the case in the only
languages I'm familiar which which provide operator overloading), the
distinction you are making disappears. You have to know what types of
the arguments are, before you can determine which overload is being
invoked. The difference between operator+() and add() is merely a matter
of notational convenience; what you've presented is an argument against
function overloading in general, not operator overloading in particular.
And, insofar as you can trust the person who wrote the code to have done
a decent job, you really don't need to know which overload is being
executed in order to understand the code. If that person overloaded
operator+() reasonably, then it does something that is analogous to
addition; if it isn't clear from context what that something is, then
it's not a reasonable candidate for operator overloading. Similarly, if
the name of the add() function was chosen reasonably, then it does
something ... [repeat rest of previous sentence, with appropriate
adjustments].
When you're debugging, then inherently the trust is gone. However, in
precisely that context, if you're using a language that supports
overloading, you should be using an IDE that will keep track for you of
which overload it is that is relevant. Without such an IDE, you're
better off not even using overloading.
I'd never let a beginner work on my code without close supervision,
unless I had no other choice (which has, unfortunately been the case
more often than I'd like).
B
Ben Bacarisse
James Kuyper said:
*My* distinction remains. My point was that without overloading (of
anything) I need to know one thing -- the definition of the operator
or function. With overloading, I need to do an extra lookup first:
determine the type, then find the definition.
Your point (which I accept -- I started with "yes") is that there is
no real difference between x+y and add(x, y) -- just syntax. I agree
but, in both cases, overloading complicates matters to a small extent.
R
Richard Bos
Kaz Kylheku said:
True, but it's not clear for mixed types. And that is the real problem
with overloading, especially with overloaded operators: they can be
applied to random types, and in doing so, can get rather confusing. For
example, after
char *a="5", *b="5", *c;
c=a+b;
is c now "55" or "10"? Without delving into the way that operator has
been overloaded in this program, you don't know. And that's a simple
example; it can get much hairier.
Besides, if at all possible, you'd arrange things so that you could
write
a = add(b, c);
which is rather less unreadable.
True; however, operator overloading is a feature with maximum confusion
capacity for very little added power.
Everything we can do with operator overloading can already be written in
the existing C language with very little trouble, and usually with less
likelihood of obfuscation.
We're not discussing the removal of anything, here; we're discussing
restraint in adding features.
If you can find a way to add overloading to the C Standard in such a way
that only types which normally would be seen as more-or-less compatible
can have their types overloaded - for example, only arithmetic types -
_and_ find a committeeable way of phrasing your proposal, feel free to
suggest it. Otherwise, I don't believe it's worth the trouble.
Richard
J
jacob navia
Richard said:
You raise a valid point. Within my proposal, there is a lot of
room for bad use, as in any proposal, as in the language
itself. Note that if I write using standard C:
There is no way to know what "Add" does without going
to read the definition of "Add".
qfloat a,b,c,d;
d = ((a-b)+sqrt(a+b))/(d*c+sin(a));
Now your notation does what?
Numbers adapt themselves VERY WELL to this notation. Problems
start when you use this notation for something else than
numbers!
Another BIG application of operator overloading is access to generalized
containers using the [ ] notation
String a; // "String" is a counted character string
a[2] = 'b'; // overloaded operator [ ]
V
vippstar
With a proper text editor, it's really quicker. I'd say it could be
possible for me to know the moment I put my cursor over "Add".
R
Richard
This is one of those discussions where I boggle at some views. Having
been involved in large C++ code bases I know from my own experience that
unless someone with very strange habits is naming the functions then
reading/debugging code with function calls is infinitely easier than
reading/debugging code which uses operator overloading in 99% of
cases. Sure if you limit the use of operator overloading then its not so
bad, but purely from a "practical, I use my eyes" approach to code I
have rarely seen operator overloading add much except complexity to any
C "like" code.
Code might be 1% creation and 99% maintenance over years. Especially in
the context of this group where portability hints at it being
distributed across multiple platforms too.
C
Chris Torek
(Digression on operator overloading, which is really just syntactic
sugar for function calls. Note that function calls can also be
overloaded in various languages, as in <tgmath.h> in C99 or
type-signature-based function call resolution in C++.)
Indeed. Of course then the expansion of "first root of quadratic
equation" presumably has to go back to either the operator version
or the function-call version. So to some extent, this merely
pushes the question back a step. But this is very important, and
perhaps even the most important thing of all, in programming:
As I have said before, the real heart of computer programming is
abstraction, in which we go from "here is a series of very explicit
and tiny steps to take to solve some particular problem" to "please
solve this particular problem for me". Finding the right abstractions,
and putting them together into a single "problem solving box", as
it were, allows us to take the problem-solving boxes and put *those*
together, to solve bigger and more interesting problems. Soon,
instead of "compute quadradic root", you may be doing things like
"obtain this food I would like to eat" or "find better way to deal
with energy crisis". (Quadratic equations will probably be involved
somewhere along the way. )
Syntactic sugar, whether in the form of operator overloading or
function overloading or anything else, is merely a small (albeit
useful) tool in doing the abstraction that allows us to solve more
interesting problems. Try not to get too hung up over syntax;
semantics matter more, and proper abstraction makes the semantics
clearer.
sugar for function calls. Note that function calls can also be
overloaded in various languages, as in <tgmath.h> in C99 or
type-signature-based function call resolution in C++.)
Indeed. Of course then the expansion of "first root of quadratic
equation" presumably has to go back to either the operator version
or the function-call version. So to some extent, this merely
pushes the question back a step. But this is very important, and
perhaps even the most important thing of all, in programming:
As I have said before, the real heart of computer programming is
abstraction, in which we go from "here is a series of very explicit
and tiny steps to take to solve some particular problem" to "please
solve this particular problem for me". Finding the right abstractions,
and putting them together into a single "problem solving box", as
it were, allows us to take the problem-solving boxes and put *those*
together, to solve bigger and more interesting problems. Soon,
instead of "compute quadradic root", you may be doing things like
"obtain this food I would like to eat" or "find better way to deal
with energy crisis". (Quadratic equations will probably be involved
somewhere along the way.
)Syntactic sugar, whether in the form of operator overloading or
function overloading or anything else, is merely a small (albeit
useful) tool in doing the abstraction that allows us to solve more
interesting problems. Try not to get too hung up over syntax;
semantics matter more, and proper abstraction makes the semantics
clearer.
S
santosh
Chris said:(Digression on operator overloading, which is really just syntactic
sugar for function calls. Note that function calls can also be
overloaded in various languages, as in <tgmath.h> in C99 or
type-signature-based function call resolution in C++.)
Indeed. Of course then the expansion of "first root of quadratic
equation" presumably has to go back to either the operator version
or the function-call version. So to some extent, this merely
pushes the question back a step. But this is very important, and
perhaps even the most important thing of all, in programming:
As I have said before, the real heart of computer programming is
abstraction, in which we go from "here is a series of very explicit
and tiny steps to take to solve some particular problem" to "please
solve this particular problem for me". Finding the right
abstractions, and putting them together into a single "problem solving
box", as it were, allows us to take the problem-solving boxes and put
*those*
together, to solve bigger and more interesting problems. Soon,
instead of "compute quadradic root", you may be doing things like
"obtain this food I would like to eat" or "find better way to deal
with energy crisis". (Quadratic equations will probably be involved
somewhere along the way.
Syntactic sugar, whether in the form of operator overloading or
function overloading or anything else, is merely a small (albeit
useful) tool in doing the abstraction that allows us to solve more
interesting problems. Try not to get too hung up over syntax;
semantics matter more, and proper abstraction makes the semantics
clearer.
But then "proper" abstraction depends on adequate syntactic support and
for humans, a language (i.e., syntax) that forces the brain to consider
too many extraneous details (extraneous to the brain, but essential for
the CPU, unfortunately, or perhaps fortunately?), tends to derail it
from it's finer flights of creativity. The human brain has a natural
tendency to see the forest rather than the trees (well, for most
individuals I suppose), while the CPU and it's PLs insist on making the
brain consider each cell of each tree in the forest.
So yes, as you said, building truly reusable and natural abstractions
without forcing either the CPU or the brain to too much inefficiency is
the most complex part of programming.
A
Antoninus Twink
Obviously for arithmetic types, +, -, etc. are clearer.
For abstract types, operator overloading does lead to completely
incomprehensible code. You've only got to look at the first operators
people learn in their C++ hello world program: << and >> absurdly
"generalized" to concatenation operators than have no conceptual
relationship to bit-shifts. If you give people the power to overload
operators on arbitrary types, then they *will* abuse it, even the
supposedly brilliant Strustrup.