Rick wrote in message <371a59c3.0@news.povray.org>...

[snip]
>/\/\oment
[snip]

So I guess you got that "m" with cut-and-paste from somewhere else, hmm?


;-)

Johannes,

Post a reply to this message

Ken wrote:
> 
> Margus Ramst wrote:
> >
> > The reason would be that you can use this in a pigment or a density, whereas
> > by #declaring you would be restricted to one of the two.
> >
> > You can't do this:
> >
> > #declare Pattern=pigment{...}
> > media{density{Pattern}}
> >
> > or vice versa.
> >
> > Margus
> 
>  I will buy your argument where disallowed functions are concerned and
> you will note I carefully avoided that trap with the second example I
> provided. The reason I ask though comes from the fact that where I have
> been observing the use of this macro peculiarity there have been only
> one instance of the macro used in the file. No dual functionality was
> apparent so the implementation seems out of place and quite frankly
> unnecessary as well.
> 
>   Thank you for pointing out the potential duality for this and it is
> worthy of taking note of for future use.
> 
> --
> Ken Tyler
> 
> mailto://tylereng@pacbell.net

Also note the difference if you use something like rand() inside the
macro/#declare.
If you think you might do this at some time in the future, then you'd
best decide at the start how you want it to behave.

PoD.

P.S. I know this response took a while, I've been wandering around in
Linux newbie land for the last few weeks :)

Post a reply to this message

> THe #declare _should_ parse faster, since there is no need to jump in the file.
> I won't stand for it, and if you ask me, i wasn't sending this message :-)

> I think there is a memory-difference as well, esp. when using several objects
> with the same density(in this case)

	Speaking as one who has advanced beyond the BS of compiler
salesmen ... :) 

	Whatever it is optimized for is what it is fastest at. Rule one,
optimize for the benchmark tests. 

	That is why the benchmark tests are so diverse.

Post a reply to this message