|
![](/i/fill.gif) |
On Sat, 21 Feb 2004 22:26:59 -0500, Christopher James Huff
<cja### [at] earthlink net> wrote:
>In article <403814c4$1@news.povray.org>, "Tek" <tek### [at] evilsuperbrain com>
>wrote:
>
>> Well, I know a good argument against it. So good in fact that it's the reason
>> why every games programmer I know doesn't use operator overloading: It hides
>> processing.
This might be a 'learning' problem if you aren't aware of the
operators 'hidden' complexity.
>So do functions.
Yes, same problem here. There's no correlation between length of
function name and complexity.
If you call a Trace() function you should know why.
May be to write a trace record to a log file, may be to start a render
that will be finished some months later.
>[...]
>> Of course, for less speed critical stuff like describing POV scenes, I'd
>> wholeheartedly support it. But I'm just saying there *is* a good argument
>> against it.
May be, but it isn't speed.
For example, I have rewritten POV-Ray's core using VECTOR, COLOUR and
some other classes (with appropriate operators).
It was as fast as the original version but shorter and IMHO much more
readable.
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.
OK, I'll stop now ;-)
>I still haven't heard one yet.
--
Andreas
Post a reply to this message
|
![](/i/fill.gif) |