 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Variables can act as any type. Like this
#declare A="35542";
#declare B="35542"; #debug concat("A,B",A,B"\n")
#declare A=45; #debug concat("A =",str(A,0,0),"\n")
#declare B=-45; #debug concat("B =",str(B,0,0),"\n")
#declare A=<4,5,6>; #debug concat("A= <",vstr(3,A,",",3,3),">\n")
#declare B=B+<6,5,4>; #debug concat("B= <",vstr(3,B,",",3,3),">\n")
#declare A=box{-1,1}
#declare B=pigment{Red}
object{A pigment{B}}
This works on 3.7 & 3.8 win versions.
Have Fun!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 2025-09-25 à 18:45, Leroy a écrit :
> Variables can act as any type. Like this
>
> #declare A="35542";
> #declare B="35542"; #debug concat("A,B",A,B"\n")
> #declare A=45; #debug concat("A =",str(A,0,0),"\n")
> #declare B=-45; #debug concat("B =",str(B,0,0),"\n")
> #declare A=<4,5,6>; #debug concat("A= <",vstr(3,A,",",3,3),">\n")
> #declare B=B+<6,5,4>; #debug concat("B= <",vstr(3,B,",",3,3),">\n")
> #declare A=box{-1,1}
> #declare B=pigment{Red}
> object{A pigment{B}}
>
> This works on 3.7 & 3.8 win versions.
>
> Have Fun!
>
I think that already worked like that with version 3.5...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Alain Martel <kua### [at] videotron ca> wrote:
> I think that already worked like that with version 3.5...
He knew.
And we all knew he knew.
He just didn't know he knew.
Once that he knows that he knew he knew, he'll see that it's nothing new.
And I knew that's it nothing new too.
- BE
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Leroy" <whe### [at] gmailcom> wrote:
> Variables can act as any type
I guess I didn't learn all the tricks of POV. When I first came to POV it was
from Qbasic and thought that a float is a float is a float, not a string or
anything else. I carried that on for more than 20 years.
The only reason I found out was because of You Tube with it topics of the worst
and best programing styles. While playing with macros, trying to make my POV
files hard to read or easier to write in win3.7. Macros need to have the
variable define before using it as an input there. So I wrote a macro to declare
a variable and its type with a string. It worked great. I set it up so that you
could declare an unlimited number of variables with a single string(with one
line of code). Cool!
I had replace #declare with macro Set(A,B) [#local A=B]. While testing things
out I accidently had A & B different types. That was IT.
If everyone knew this why haven't we have a contest to write code creating the
most complicated scene with the fewest variables used?
I guess it would end a tie with 2 or 3 variables.
Have fun!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I Dont understand where is the problem.
I executed the code in the expectation that something great would happen.
disappointed,
ma
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Maetes" <nomail@nomail> wrote:
> I Dont understand where is the problem.
>
> I executed the code in the expectation that something great would happen.
>
> disappointed,
> ma
Sorry there is no problem. I thought that the behavior of changing types of a
variable on the fly was interesting. It is strange coming from C or C++ where
types are written in stone. And another interesting thing is that it took me so
long to find it!
Have Fun!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 2025-09-25 18:45 (-4), Leroy wrote:
> Variables can act as any type.
There are some exceptions:
- Macro names cannot be reused as another type without being #undef'd.
- Function names cannot be reused--even as another function--without
being #undef'd.
- Function formal parameters cannot take the name of any existing
identifier.
Notwithstanding the above, macro formal parameters can always reuse any
name.
Irritatingly, these apply even to local identifiers, meaning that truly
modular programming is impossible in POV-Ray. If you write a public
include file, you must make sure that your local variables do not
conflict with any macro names that any other POVer might ever use. If
you write a function that has any formal parameters other than u, v, x,
y, or z, you must choose parameter names that do not conflict with any
identifier of any type that any other POVer might ever use. And if
you're just creating a scene file, you always run the risk of your
script bombing out because of conflicts with the innards of include
files that, by rights, you shouldn't have to know about.
The fact that macro formal parameters can reuse macro and function names
shows that this scope leakage is not logically inevitable. It may take
a lot of work on the parser to fix this design flaw, but I think it
should be a priority.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 2025-09-27 13:10 (-4), Leroy wrote:
>
> And another interesting thing is that it took me so
> long to find it!
I suppose this is a sign that you've been using good programming practices.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
