On Sun, 22 Feb 2004 01:11:47 -0800, Tek wrote:

(Just a hint: start a new thread "Cast operators are evil" and I'll
agree at once)

>My point is that a+b takes a different length of time according to the types of
>a and b, where as MyMatrixAddFunction(a,b) takes the same length of time always,

I don't know what you want to state above. I think everybody will
agree that adding two matrices will take more time than adding two
integers. An operator adding two matrices takes the same time as your
MyMatrixAddFunction() function.
 
>plus you can search for it to see where it's executed in the code,

Ok, this might by an advantage.

>plus you can
>stick a nice big comment on the prototype of it saying "//avoid calling this
>unless really necessary, it's very slow" so that anyone who doesn't know how to
>add these two things has to look up the function prototype and read the comment
>and reconsider the code they're writing.

If someone is new to the project (as he doesn't know how to add 'these
two things') you have to train him anyway.
Using appropriate operators is IMHO more intuitive (and as fast as
your My...Function() above).

>I'm not trying to suggest the source looks nicer with more function calls, it
>certainly doesn't. I'd even say I like operator overloading a lot, it's
>extremely useful in high-level programming applications. I'm merely saying that,
>in practice, it makes it easier to write code that is much more complex to
>execute than it is to read or write. This is both it's strongest and weakest
>point.

I don't get the point. All that I know if I see 'My...Function(a, b)'
in the code is "Either a or b, or both of them are not simple types",
it doesn't give me any hint/warning about it's complexity.

>> The macros required to do trivial colour/vector arithmetic are
>> 'information hiding' in the worst sense. They blow up source code and
>> add visual noise which makes it sometimes almost impossible to see
>> what's going on.

>As I said, I support using + for vectors since that's what it will compile to.
>Although I don't really see your point about visual noise, function calls

Think of the core steps of an algorithm as signal, the code you
write/read as noise.

>certainly make it harder to write clearly readable code but since it's harder
>all it takes is more effort.

Yes. Harder to write it once, *and*
- harder to read always,
- harder to find bugs,
- easier to hide bugs,...

>Programming isn't about making things easier for
>the programmer, it's about making the end result better. In application software
>or high level programming these two ideas are very compatible, but in time
>critical stuff like game engines people like me have to give ourselves headaches
>trying to optimize out one cycle in a render loop in order to improve the
>performance of the game. Operator overloading hinders us in this quest.

>Damn that made me sound so cool...

:-)

-- 
Andreas

Post a reply to this message