POV-Ray : Newsgroups : povray.general : #declare blah =3D -1; // bug avoidance (avoids "incomplete function or s= : Re: #declare blah =3D3D3D3D -1; // bug avoidance (avoids "incomplete fun= Server Time
1 Aug 2024 04:14:17 EDT (-0400)
  Re: #declare blah =3D3D3D3D -1; // bug avoidance (avoids "incomplete fun=  
From: Charles C
Date: 7 Aug 2006 13:45:01
Message: <web.44d77bfa10f9b831b160ffde0@news.povray.org>
Thanks guys,
Unfortunately I don't think I'm out of the woods yet on this one.

I had actually run into problems sometime back when modifying variables
named by the parameter line of a macro.  So, ever since then I've made a
point of declaring a local variable to take it's place if need be.  E.g.

#macro DoSomething(Variable)
   #local TempVariable = Variable;
   #declare TempVariable = Variable + 1;
#end


So I suppose it could still somehow be related to the parameter bug, but I
suspect this is something else. Also, last night I found a case where the
"offending" line wasn't even a function or spline call... It was just a
#declare statement, in this case, still having to do with splines.  It was
something like:

#declare MySpline2 = MySpline1;

....And That's about it.   I tried adding a line above it:

#ifndef(MySpline1) #error "uh oh"  #end

....but unfortunately this line made it parse.  As I said, any little change
elsewhere up above in the code can change whether a likely offender
actually offends.

So far I've found 3 types of offenders:

1.  A call to a macro which creates triangles between 2 splines which are
passed as parameters.
2.  A call to a macro which generates a spline using points from other
splines.  A single float is passed to this macro to tell it what point
along those other splines to use.
3. #declare MySpline2 = MySpline1; //or something like this.

(None of these involve modifying parameters.)

Thanks again,
Charles



Thanks again,
Charles


Post a reply to this message

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