POV-Ray : Newsgroups : povray.pov4.discussion.general : Suggest v4.0 read only identifiers. (yuqk R15 v0.6.9.0) : Re: Suggest v4.0 read only identifiers. (yuqk R15 v0.6.9.0) Server Time
19 Jul 2024 22:28:32 EDT (-0400)
  Re: Suggest v4.0 read only identifiers. (yuqk R15 v0.6.9.0)  
From: William F Pokorny
Date: 28 Jun 2024 09:40:40
Message: <667ebd58$1@news.povray.org>
On 6/28/24 01:13, ingo wrote:
> William F Pokorny <ano### [at] anonymousorg> wrote:
> #macro Add(_immuInt, otherInt)
> ......
> #end
> #declare Res = Add(99,1)
> #declare _immu = 99;
> #declare Res = Add(_immu, 1)
> In the second use of the macro, would it be required that the 'referenced' value
> is also declared immutable?
> ingo

If I'm understanding you, no with respect to the macro, identifier pass 
by reference issue.

As long as you have _immuInt as the first macro Add() parameter name, 
the call can be Add(_immu,1) or Add(Res,1) and neither _immu or Res can 
be changed by any #local or #declare use of _immuInt inside the macro.

That said, the Res identifier is not protected from someone writing:

     #declare Res = 42;

inside the macro while  	

     #declare _immu = 42;

will be illegal inside the Add() macro. So, it's not necessary the _ 
prefix immutability be indicated in both the macro parameter and more 
global calling space - but it is a good idea, if you want protection 
from someone making more global changes from within the macro.

Related. The hole in the prefix based constant-ness is that it is NOT 
propagated into macros called. For example,

#macro Add(V1,V2)
     #local V1 = V1+V2;

    #declare _immu = 42;
    #declare Val99 = Add(_immu,1);

will still result in the _immu getting clobbered. The best practice 
would be to always use macro parameter names with the _ prefix - unless 
you are truly aiming to change identifiers by reference inside the 

Bill P.

Post a reply to this message

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