POV-Ray : Newsgroups : povray.advanced-users : Object Oriented POV code : Re: Object Oriented POV code Server Time
29 Jul 2024 14:14:01 EDT (-0400)
  Re: Object Oriented POV code  
From: Patrick Elliott
Date: 22 Feb 2004 17:31:27
Message: <MPG.1aa2db602f53d3599899b6@news.povray.org>
In article <4037f302@news.povray.org>, war### [at] tagpovrayorg says...
> Patrick Elliott <sha### [at] hotmailcom> wrote:
> > But it can happen.
> 
>   Of course it can happen. And it can also happen that a function
> named "multiply" calculates the square root. But that doesn't mean
> it's not avoidable. It just means the design of the program/library
> has a flaw.
> 
But is it always a flaw?

For example, say you want to manipulate an image:

Fade(Object.DC)

function Fade(myDC AS DC ByRef)

Do you want Fade to have *only* the contents of the DC, which could be 
40x40 or 80x20 or even 1600x1? No, you pass it a reference to the DC, so 
you can manipulate the original contents.

You could also pass the DC to the function with it automatically making a 
copy by using it like:

Object.Image = Fade(Object.DC)

function Fade(myDC AS DC ByVal)

But you are performing two copies here, instead of just manipulating the 
actual data. This will take more time and added memory to accomplish. Why 
exactly do you think the first version is bad design? It makes a whole 
heck of a lot more sense that wasting extra processor cycles making 
copies, instead of performing the effect on the original image. Yes, this 
may not be the 'best' way in some case, but what if you do this:

set a = GetCompatibleDC(Object.DC)
Grayscale(a)
Fade(a)
FindEdges(a)
Object.DC = a

That eliminates 6 extra copy processes you have to make by passing the 
contents of the DC, instead of a reference to the one copy your actually 
needed. This is not *bad* library design.

-- 
void main () {

    call functional_code()
  else
    call crash_windows();
}


Post a reply to this message

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