POV-Ray : Newsgroups : povray.general : #ifdef using a string expression? : Re: #ifdef using a string expression? Server Time
3 Jun 2023 10:33:16 EDT (-0400)
  Re: #ifdef using a string expression?  
From: Alain Martel
Date: 20 Mar 2023 11:11:17
Message: <64187795$1@news.povray.org>
Le 2023-03-19 à 10:41, Bald Eagle a écrit :
> "Kenneth" <kdw### [at] gmailcom> wrote:
>> Given the current mix of flaws, the use of a string literal still has me
>> scratching my head...
>>          #ifdef("...string...")
>> Alain's and JR's explanation of the expected behavior seems valid; but with a
>> properly-working #ifdef, should the comparison fail outright (fatal error)? Or
>> should it still be seen as defined? I'm mostly just curious ;-)
> One might suggest:
> "Expected variable name, literal value found instead."
> -or- "It is what is is." ;)
> The correct answer for me has always been OPTIONS.
> When everything gets locked into a one-right-answer only format, it usually just
> creates new problems in the process of "solving" the old.
> I was just reading some old threads concerning this type of thing, and the
> degenerate triangle warning vs 0-length fatal error for cylinders was brought
> up.
> For some scenes it could be a critical thing to stop the render.   For others,
> you might want to just ignore them all.  Usually these things are addressed by
> the users with workarounds, but why not have a configuration file that states
> how to handle these cases, an additional argument for the object instantiation
> that provides for individual control, or an error-trapping mechanism (with error
> code) that allows the user to write their own programmatic/logical solution
> based on further testing and flow control, and allows the user to issue better
> warnings that the cryptic ones currently hard-coded in source?

Or even a global_settings entry, such as :
Ignore_degenerate true|false //default to false

Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.