"Kenneth" <kdw### [at] gmailcom> wrote:

> The string expression is considered to have been created WITHIN
> the #ifdef() itself?

Well, it's defined by you, and the parser, and yes, once the parser hits that
closing ", then it's defined, and at that point, when the closing ) of the if
def gets hit - the conditions for TRUE are satisfied.

> What seems strange to me is that #ifdef is not the same
> 'kind' of code construct as a #declare or #local, which would otherwise be
> required earlier for any other kind of entity or variable for #ifdef to operate
> on.


> Although, a string expression is not really a 'variable'; here, it exists as
> a 'literal'. Yet a 'naked' string literal cannot be used by itself as a line of
> code; that produces an obvious fatal error.

But you're not declaring the value of a variable to be the string literal, any
more than you're using a direct string literal in text {} or str {} or any other
operator.



>
> So is a string expression the only kind of 'thing' that #ifdef sees as defined?
> Nope. Even an arbitrary float value behaves the same way:
>
> #ifdef(7.6)
> ...do this... // success
> #else
> ...do that...
> #end
>
> To me, this would seem to be an unexpected trap, waiting to be 'exploited' by
> mistake. I'm not sure how such a mistake might be made by a user, but still...


This is the way POV-Ray works with "Boolean" values (and IIRC, so do other
computer languages) O is false, and any non-zero value is true.
Send the str value of true to debug and see what it is.  It's a common shorthand
to use 0 and 1 for t&f or the setting of "flags" in code.

I often (ab) use this tool/trick to save some typing when doing loops.  If I'm
starting a loop at zero, then all I have to do is #ifdef(loopVariable) instead
of #if (loopVariable > 0).   Stuff like that.

(And to head off your purely theoretical complaint, 7.6 IS a number, and so it
IS defined when that ) closes the #ifdef statement.
You might try that with 0 and see what happens, but remember that we have to
have SOME way of signifying certain states, and we don't have proper variable
type casting in POV-Ray, so we rely on numerical values to represent
"undefined"/"null", NaN, and likely others.
Since we also have 2 parsers, you're likely to find other "surprises" in the
function parser behaviour.  ;) )

Also keep in mind that some variables that _were_ declared, will not be any more
- such as temporary macro arguments, loop counters, #local variables in include
files, etc.

Other things might be defined, or have defined values other than what you
thought they were, depending on how they've gotten to the point in the code that
you're at.  jr and Cousin Ricky have correctly pointed out that you can pass
things into macro calls "by reference" rather than "by pointer".


http://news.povray.org/povray.advanced-users/message/%3C5a02fe60%241%40news.povray.org%3E/#%3C5a02fe60%241%40news.povra
y.org%3E


Simply having a short script that sent all the various test results to #debug
would be a good reference, esp for reminders/new users (and testing new
versions).

Post a reply to this message