On 2020-06-27 11:05 AM (-4), Bald Eagle wrote:
> Cousin Ricky <ric### [at] yahoocom> wrote:
>> One just has to keep in mind POV-Ray's scope leakage
>>  If you have formal computer science education, you are mortified by
>> these restrictions, wondering how people smart enough to create POV-Ray
>> could have allowed such boneheaded violations of modular practice. I am
>> assured that the current development team is aware of such problems.
>> Yes, I will keep complaining about the scope leakage until it is fixed.
> This is an area where I've harbored suspicions and trepidation, due to
> subconscious knowledge gathered from reading the newsgroups and docs over the
> past years.
> Jr and I have recently been working on some code, and while implementing /
> rewriting a macro, some recursion was introduced, and a variable identifier was
> passed back into the macro as an argument. Debugging hilarity ensued.
Ah, yes, I've run across this before. Take a look at macro CH2RGB() in
colors.inc. The parameter HH used to be H before I blundered into the
pass-by-reference trap and my scene file fell into an infinite loop.
Thanks to Jerome for figuring out the problem, and to whoever fixed it
in time for the POV-Ray 3.7 release.
I ran across it again in Lightsys IV. (That bug was also fixed in 2012.)
Which area are you concerned about, scope leakage, or accidental
> If I understand it all correctly:
> When you #declare variable N to have some value, and then use N as the
> "temporary" variable name of what gets passed into the macro, and then use
> #local to declare N's new in-macro / in-loop value .... the global / higher
> level value of N gets redeclared.
> So apparently "POV SDL apparently makes no distinction between passing-by-value
> and passing-by-reference, as other languages do."
I would say that it does, but the distinction is not explicit; the
distinction manifests in how you express the argument, as you have
> Now here's the interesting part - which I had NO IDEA was even a thing:
> "turns out, there's a (documented *) way to force POV-Ray to always treat a
> macro argument as pass-by-value. Add a '+' in front of the identifier name and
> voila, POV-Ray is not "not allowed" to pass-by-reference because we're not using
> an identifier, but an expression.
> will leave N alone."
I have no problem with this. At the *very* worst, it's a "I don't like
the way this works so it must be a bug," but I won't even go that far.
While pass-by-reference is dangerous if misused, it is still an
important tool, and making POV-Ray strictly pass-by-value would
compromise its flexibility. C can be strictly pass-by-value it because
one can pass an address to effect pass-by-reference.
While I admit it would be nice for POV-Ray to have an explicit
distinction between pass-by-value and pass-by-reference, I would give it
a low priority. POV-Ray's implicit distinction is clearly defined and,
as you have noted, well documented, confusing though it may be. As long
as you are careful with your coding, it is not a problem.
Scope leakage is a different matter.
Post a reply to this message