POV-Ray : Newsgroups : povray.advanced-users : Object Oriented POV code : Re: Object Oriented POV code Server Time
29 Jul 2024 08:23:07 EDT (-0400)
  Re: Object Oriented POV code  
From: Andreas Kaiser
Date: 22 Feb 2004 00:10:11
Message: <n8ag309hemfhpmj8jnt5j5s3k8gr66rm62@4ax.com>
On Sat, 21 Feb 2004 22:26:59 -0500, Christopher James Huff
<cja### [at] earthlinknet> wrote:

>In article <403814c4$1@news.povray.org>, "Tek" <tek### [at] evilsuperbraincom> 
>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

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.