William F Pokorny <ano### [at] anonymousorg> wrote:
>

Thanks for doing such a detailed series of tests and an examination of the
various code versions! I can imagine that it was a lot of drudgery.

> I think we need to start with the fact #ifdef, #ifndef and #undef have
> ALWAYS been #ifIdDefined, #ifIdNotDefined and #undefineId. Going back to
> the v3.6 documentation we have:
> [clip]
>
> We need functionality which deals only with IDs.
>
> ...but the generic sort being allowed or not seems
> questionable to me.

I agree; IMO, #ifdef etc. should adhere to the much more strict behavior
described in the docs. Admittedly, I am not as sophisticated a user of these
functions as some others are, but the current behavior seems quite lax and could
lead to unintended scene errors or coding 'mysteries'.

And I would be happier if my silly string-literal example produced a fatal
error! Otherwise, I can't imagine a scenario where a 'naked' string would even
be used there.

I also think that using an *actual* zero or a float (while having some meaning
as boolean values) does not really represent a 'valid ID' as per docs, and so
should fail outright as well. My opinion ;-) HOWEVER... I can see a scenario
where 0 or 1 could be used simply to test whether a scene's specific #ifdef
construct is working properly or not-- in other words, without relying on an
actually-defined identifier for the test. On the other hand...it would be a
simple matter to pre-define a temp dummy identifier for the same use.

> Christoph went on to add a bunch of inbuilt keywords to be considered
> 'defined' sometime after late November 2018 - which makes me begin to
> think he too might have been considering these *def keywords in the
> c/c++ coding, macro test sense.

Actually, it's not clear to me why any keywords at all would or should be valid
'parameters' for an #ifdef comparison-- but I'm rather naive at present about
what might be such a useful coding scenario. For example, my own rather
meaningless(?) test of
               #ifdef(true)
appears to be a flat-out mistaken use of the function, since the comparison will
(or rather, *should*) always invoke the first clause, never the #else. In other
words, this construct should use #if or #while or #switch or etc, not #ifdef.

I am obviously not seeing why a keyword could be meaningfully used there.


----------
In general, I think that most of not all of the non-fatal error messages re:
#ifdef should be changed to fatal-- if only as a guard against using entities
that don't belong there and need changing. Personally, I'm lazy about taking
note of non-fatal messages.

Post a reply to this message