>   I just gave a simple example and wanted to point out that using operator
> overloading does not add any overhead whatsoever to regular function calls.

I never said it did.

Oh dear, oh dear, I seem to have confused you. I'll try to explain:

What I said is that if you have a + between two ints it compiles to less code
than if you have a + you've defined as an overload operator *for a more complex
type*.

i.e. the code looks the same, but it does more stuff (because the data it's
operating on is more complex). This is *good* from an OO point of view, because
you don't need to know about the implementation of the object in order to use
it, but bad from an optimisation point of view, because you do need to know
about the implementation in order to be able to use it *efficiently*.

>   Using operators makes the code cleaner and easier to read with complex
> expressions.

So what if it's easier to read? A good programmer can deal with code that's hard
to read, it's good if it's readable but not if you've lost some information you
might want.

>   If you don't know what operator+() does with the type you are using,
> then you should seek another job, IMHO.
>   If you are making speed-critical code then you should know your tools.

Right, lets say your product ships in two weeks time, and you've discovered that
the physics guy who got sacked last week was a moron. Hey, it happens. You need
to go through his code and find everywhere that he's performing a matrix*vector
multiply, in order to replace it with a more efficient piece of code.

How do you do that?

-- 
Tek
www.evilsuperbrain.com

Post a reply to this message