 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
(v3.8.0 beta 1 in Windows 10)
I was playing around with #ifdef recently; just experimenting.
I put a nonsense string expression into it-- not actually defined anywhere-- to
see what would happen:
#ifdef("htenneK")
....do this...
#else
....do that...
#end
Instead of issuing an error message or even a fatal error as I half-way
expected, it actually fell through to the *first* clause successfully. Without
the double quotes, it works as expected and falls through to the #else.
Should #ifdef behave this way? Is the first double-quote causing some kind of
unforeseen problem for the parser?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 2023-03-14 à 08:43, Kenneth a écrit :
> (v3.8.0 beta 1 in Windows 10)
>
> I was playing around with #ifdef recently; just experimenting.
>
> I put a nonsense string expression into it-- not actually defined anywhere-- to
> see what would happen:
>
> #ifdef("htenneK")
> ....do this...
> #else
> ....do that...
> #end
>
> Instead of issuing an error message or even a fatal error as I half-way
> expected, it actually fell through to the *first* clause successfully. Without
> the double quotes, it works as expected and falls through to the #else.
>
> Should #ifdef behave this way? Is the first double-quote causing some kind of
> unforeseen problem for the parser?
>
>
>
>
As I see it, #ifdef() test the existence of an entity.
With the quotes, the string DO exist, IS defined, even if it only exist
locally. So, the test returns true.
Without the quotes, it test if the variable exist, and, if it wasn't
#declare beforehand, will return false.
So, I think that it behave as it should.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
hi,
Alain Martel <kua### [at] videotron ca> wrote:
> > I was playing around with #ifdef recently; just experimenting.
> >
> > I put a nonsense string expression into it-- not actually defined anywhere-- to
> > see what would happen:
> >
> > #ifdef("htenneK")
> > ...
> As I see it, #ifdef() test the existence of an entity.
> With the quotes, the string DO exist, IS defined, even if it only exist
> locally. So, the test returns true.
> Without the quotes, it test if the variable exist, and, if it wasn't
> #declare beforehand, will return false.
>
> So, I think that it behave as it should.
agree, ref: <https://wiki.povray.org/content/Reference:Strings#String_Literals>
regards, jr.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Alain Martel <kua### [at] videotronca> wrote:
> >
> As I see it, #ifdef() test the existence of an entity.
> With the quotes, the string DO exist, IS defined, even if it only exist
> locally. So, the test returns true...
>
> So, I think that it behave as it should.
Sorry for the delay in responding; I had to think about this behavior for
awhile.
I guess it must certainly be so, and I sort of sense the logic of it...but it
does seem odd: The string expression is considered to have been created WITHIN
the #ifdef() itself? 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.
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...
My two-cents ;-)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 3/18/23 08:59, Kenneth wrote:
> 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...
>
> My two-cents 😉
I agree with three-cents - and now we have five! :-)
I took a quick look just now and v3.7 works as expected in some quick
testing in that only identifiers are OK - which I do believe is the intent.
So, I'd say this is another v3.8 beta 2 bug.
It's something with the changes in parsing, but it must have happened
prior to Christoph's back off point for the v3.8 parser too.
Bill P.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Bald Eagle" <cre### [at] netscapenet> wrote:
> >
> > 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
> >
> 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.
Yep, I get that-- if the #ifdef is seeing it as boolean, that is. But here's a
weird thing (well, weird to me at this point of my fuzzy understanding):
#ifdef(true)
is apparently seen as NOT defined, and falls through to the #else. Of course,
I'm not even sure if that construct makes any sense code-wise or syntax-wise.
>
>
> (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...
Strangely(?), this has the same result as above: #ifdef(0) falls through to the
first clause. So maybe the 'boolean' explanation doesn't hold for #ifdef?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Kenneth" <kdw### [at] gmailcom> wrote:
>
> Strangely(?), this has the same result as above: #ifdef(0) falls through to the
> first clause. So maybe the 'boolean' explanation doesn't hold for #ifdef?
oops, sorry---
"Strangely(?), this does NOT have the same result as above: #ifdef(0) falls
through to the first clause" (and so is seen as defined.)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Kenneth" <kdw### [at] gmailcom> wrote:
> Yep, I get that-- if the #ifdef is seeing it as boolean, that is. But here's a
> weird thing (well, weird to me at this point of my fuzzy understanding):
> #ifdef(true)
> is apparently seen as NOT defined, and falls through to the #else. Of course,
> I'm not even sure if that construct makes any sense code-wise or syntax-wise.
And you get that to work without a warning?
My few test cases resulted in:
#ifdef ("String") returns true.
#ifdef (1) returns true.
#ifdef (0) returns true.
"C:\Users\Mini\Documents\POV-Ray\v3.8-beta\scenes\DefinedValues.pov" line 13:
Parse Warning: Tried to test whether a reserved keyword is defined. Test result
may not be what you expect, and may fundamentally differ in future
versions.
#ifdef (true) returns false.
#ifdef (tau) returns false.
#ifdef (pi) returns false.
#ifdef (pigment) returns false.
#ifdef (if) returns false.
"C:\Users\Mini\Documents\POV-Ray\v3.8-beta\scenes\DefinedValues.pov" line 15:
Parse Warning: Tried to test whether a reserved keyword is defined. Test result
may not be what you expect, and may fundamentally differ in future
versions.
"C:\Users\Mini\Documents\POV-Ray\v3.8-beta\scenes\DefinedValues.pov" line 17:
Parse Warning: Tried to test whether a reserved keyword is defined. Test result
may not be what you expect, and may fundamentally differ in future
versions.
"C:\Users\Mini\Documents\POV-Ray\v3.8-beta\scenes\DefinedValues.pov" line 19:
Parse Warning: Tried to test whether a reserved keyword is defined. Test result
may not be what you expect, and may fundamentally differ in future
versions.
"C:\Users\Mini\Documents\POV-Ray\v3.8-beta\scenes\DefinedValues.pov" line 21:
Parse Warning: Tried to test whether a reserved keyword is defined. Test result
may not be what you expect, and may fundamentally differ in future
versions.
-
"C:\Users\Mini\Documents\POV-Ray\v3.8-beta\scenes\DefinedValues.pov" line 32:
Note that, "Test result may not be what you expect...." because it's a keyword,
not a proper variable.
I also tried:
#ifdef (0a) #debug concat ("#ifdef (", "0a", ") returns true. \n") #else #debug
concat ("#ifdef (", "0a", ") returns false. \n") #end
and get "No matching ), undeclared identifier found instead."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 3/18/23 10:19, William F Pokorny wrote:
>> 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...
>>
>> My two-cents 😉
>
> I agree with three-cents - and now we have five! 😄
>
> I took a quick look just now and v3.7 works as expected in some quick
> testing in that only identifiers are OK - which I do believe is the intent.
>
> So, I'd say this is another v3.8 beta 2 bug.
>
> It's something with the changes in parsing, but it must have happened
> prior to Christoph's back off point for the v3.8 parser too.
Alright.
A long time ago I created a bunch of statically linked(a) versions of
POV-Ray going back through time. Anyhow. Used these to trace the
introduction of the str/num OK in #ifdef test bug.
Bill P.
(a) - This the old timer's container alternative.
---
commit 58d51f4911dce5e9021c62b30983902b0aab8b04 str,num OK
Author: Christoph Lipka <c-l### [at] usersnoreplygithubcom>
Date: Sun Mar 1 02:05:39 2015 +0100
Fixed scrambled warning messages.
// There are only five commits between the one up top and the bottom
// one below. My BIG bet is on the following commit being the problem,
// but I don't have a static compile of it or the one prior to it to
// be sure.
commit a94c1ab61aeb2aa483aa3636736ff1e24ebd8b78
Author: Christoph Lipka <c-l### [at] usersnoreplygithubcom>
Date: Sun Mar 1 02:03:14 2015 +0100
Implemented tuple extensions to #declare and #local.
...
commit 3f56c5fb8a54998067a217e54101c799756510b4 Complains.
Author: Christoph Lipka <c-l### [at] usersnoreplygithubcom>
Date: Tue Feb 3 16:48:11 2015 +0100
Fixed Unix build errors.
---
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
