Am 14.06.2021 um 15:37 schrieb William F Pokorny:
> Reality is less clean. I don't know the history, but take the
> #breakpoint parsing code enabled strictly with POV_DEBUG. It effectively
> changes the parser a little in enabling a new keyword for 'developers.'
That feature is actually a very good example of stuff that should ALWAYS
be enabled in developer debug versions, but NEVER in a hypothetical
"end-user debug versions" (except for a dedicated developer debug
The keyword is intended to flag lines in the scene file, and set debug
breakpoints anywhere in POV-Ray's code that only trigger if the parser
has already passed that line.
> Fresh in my mind because it's use shifts internal identifier enum values
> due being inserted as a new keyword for POV_DEBUG builds. I've been
> refining povr's new id_type() function and it's more or less the straw
> which prodded me to create a core shipped 'setidtypes.inc' include file
> when I'd intended to leave that job to users.
Yes, it's a very bad idea to expose any of those constants to the end
user. The values WILL be subject to change WITHOUT notice. There are
documented constraints to the list that would conflict with a policy of
"keep this list frozen forever, only ever appending to the end", even if
we were to ditch the "please keep this sorted alphabetically" policy.
It's even a very bad idea to try and catch them with hard-coded values
in a `setidtypes.inc` to be shipped with the source, because they may
even vary in DIFFERENT BUILDS of the SAME VERSION - even not considering
debug versions. Most notably, future versions may include certain
experimental features, that might require certain preprocessor switches
to be enabled. Look at `POV_PARSER_EXPERIMENTAL_OBJ_IMPORT` for an example.
For a smarter approach, consider designing a syntax to look up the
values by associated keyword, rather than hard coding them. Or by
probing constructs of known type.
(If you're already doing that, forget I said anything. I haven't found
the time & energy to have any closer look at your implementation of that
Also, it would be smart to introduce a separate dedicated datatype for
type IDs, to not even tempt users to try comparing them with numeric
literals. I'll eventually do a similar thing for stuff like RNGs and
file IDs, which are numerical internally, but make no sense exposing to
But I think I'm digressing here from the original topic.
Post a reply to this message