How might one test if an object has been created by a macro which may or may 
not produce an object, based upon various unpredictable factors? I'm trying 
to avoid the "need more than 1 object in csg" warnings.

If you place the macro call within an if statement, would it return true if 
an object has been created, and false if not?

If yes, would this be done like:

#local this = myMacro(params);
#if (this)
 union {
  object {this}
  someObject {}
 }
#end

Would it be better to perform an isCreated() test in the macro itself?

Just FWIW, I am making an extensible vine/ivy/moss/mushroom macro from a 
combination of Ron Parkers traceVines.pov (whose functionality I have 
decoupled from its intended use to facilitate extensibility) and calls to 
various macros from my framework. Its looking pretty damn good so far too. 
:-D

thanks!
ian

Post a reply to this message

[GDS|Entropy] <gds### [at] hotmailcom> wrote:
> How might one test if an object has been created by a macro which may or may 
> not produce an object, based upon various unpredictable factors? I'm trying 
> to avoid the "need more than 1 object in csg" warnings.

  FWIW, the warning is not dangerous in any way. It's just informative
and can be safely ignored.

-- 
                                                          - Warp

Post a reply to this message

"[GDS|Entropy]" <gds### [at] hotmailcom> wrote:
> How might one test if an object has been created by a macro which may or may
> not produce an object, based upon various unpredictable factors? I'm trying
> to avoid the "need more than 1 object in csg" warnings.
>
> If you place the macro call within an if statement, would it return true if
> an object has been created, and false if not?

Be sure to grasp what macros actually do. It's a common pitfall to think of them
as functions. They're *not*. Neither do they produce objects. All they do is
auto-generate SDL code at the location where they are invoked.

So if you write, e.g.:

  #macro myMacro(p1,p2)
    #if (p2 > 0)
      sphere { p1, p2 }
    #else
      // nothing
    #end
  #end

  #declare this = myMacro(VRand(myRand),rand(myRand))

then this is effectively the same as if you had rolled a dice and either
written:

  #declare this = sphere{ <...>, ... }

or:

  #declare this = // nothing

In the former case, the macro invocation generates part of a statement that
assigns a sphere object; in the latter case, the macro invocation generates
part of an invalid statement. You cannot even test for any "return value".

Note that MegaPOV has mechanisms to check for the type of a variable; so you
could have your macro generate "false" if it does not generate an object
definition; this way, you could generate a statement that always parses
properly, then check whether generated variable assignment produced an object
or a number. However, official POV doesn't have this, so if you'd try to check
the variable content with an #if(this) or #if(this != false) you'd get a syntax
error in case it is an object variable.

You *can* write a macro this way:

  #macro myMacro(p1,p2)
    #if (p2 > 0)
      #declare this = sphere { p1, p2 }
    #else
      // nothing
    #end
  #end

In that case, you could check whether the object was created by using
#ifdef(this).

Post a reply to this message

"Warp" <war### [at] tagpovrayorg> wrote in message 
news:49b3146c@news.povray.org...
>  FWIW, the warning is not dangerous in any way. It's just informative
> and can be safely ignored.
>

True, but I'm just trying to eliminate needless overhead from my macros. I 
like clean code with proper try/catch/finally implementation and memory 
optimizations.
Hmm....that gets me thinking...maybe I should actually make a 
try/catch/finally macro...

I really think things could be easier in pov if there were a nice include 
file of macros that implemented various common programming concepts.
I have been attempting this to some degree and adding it to my little 
framework. ;-D
The more I can make SDL act like C# the more I can do with it.

Roadmap:
0) Utility framework (PRVGs, Trace functions, Texture macros,etc..)
1) Snow/Ice macro
2) Icicle/Stalactite/Stalagmite macro
3) Corrosion/Funk/Peeling paint macro
4) Vine/Moss/Mushroom/Ivy macro
5) Cloud/Fog macro
6) Water macro

1-4 are just implementations of 0.

I have come pretty far with these, and have been devoting all of my free 
time to their construction. There are many features still to be added, 
optimizations to be done, and other macros I'm working on to be added later. 
I'm actually trying to build a useful and serious framework that can be used 
in just about any circumstance.

ian

Post a reply to this message

"[GDS|Entropy]" <gds### [at] hotmailcom> wrote:
> Hmm....that gets me thinking...maybe I should actually make a
> try/catch/finally macro...
>
> I really think things could be easier in pov if there were a nice include
> file of macros that implemented various common programming concepts.
> I have been attempting this to some degree and adding it to my little
> framework. ;-D
> The more I can make SDL act like C# the more I can do with it.

Duh. Sounds like a great idea, but will it be possible at all?

And anyway, I think implementing such things as macros is actually just a
kludge; implementing them in C++ as integral part of the SDL would be a much
better thing (thinking of speed, for instance).

First thing on the agenda for that would be, in my eyes, implementing dynamic
arrays. Seems like that's the thing most commonly asked for. Some other
collections might come in handy, too; for instance, some 3D lookup structure
would probably be of benefit (thinking of kd-tree or octree here).

Then a few additional statements that probably won't really speed up things
much, but make coding a bit simpler, like #for and #foreach loops.

Post a reply to this message

clipka wrote:

> You *can* write a macro this way:
> 
>   #macro myMacro(p1,p2)
>     #if (p2 > 0)
>       #declare this = sphere { p1, p2 }
>     #else
>       // nothing
>     #end
>   #end


You can also get rid of the reference to the global
variable name from within the macro by using the more
cumbersome:

#macro myMacro(p1,p2,outobjcreated,outobj)
   #if (p2 > 0)
     #local outobjcreated = true;
     #local outobj        = sphere { p1, p2 }
   #else
     #local outobjcreated = false;
   #end
#end

// Need to be initialized, value irrelevant
#declare myoutobjcreated = false;
#declare myoutobj        = false;

myMacro(<0,0,0>, -1, myoutobjcreated, myoutobj)

#if (myoutobjcreated)
   #debug "Object myoutobj is ready for use"
#else
   #debug "No object created"
#end


I'm still puzzling whether one could get rid of the myobjcreated
variable. I tried assigning "false" to myoutobj but I don't know
of any way to test whether a variable contains a float or an object,
and #if will raise an error if it is an object. I also tried
"#undeffing" outobj but that seems to only undef the local
variable name outobj, not the passed variable. Makes sense
in a general way but not so much with the output semantics
for variables passed to macro parameters: If I can change
the value of the passed variable, I should also be able
to reset it to some kind of null reference.

Post a reply to this message

[GDS|Entropy] wrote:
> How might one test if an object has been created by a macro which may or may 
> not produce an object, based upon various unpredictable factors? I'm trying 
> to avoid the "need more than 1 object in csg" warnings.

Either set a flag:

   #define YeahItWasCreated=true;

or print feedback to the console:

   #debug "Yeah, it was created.\n"

Happy to help,
John

Post a reply to this message