POV-Ray : Newsgroups : povray.general : subtle problem with /*...*/ comment block : Re: subtle problem with /*...*/ comment block Server Time
21 Dec 2024 11:52:52 EST (-0500)
  Re: subtle problem with /*...*/ comment block  
From: Kenneth
Date: 21 Dec 2024 04:30:00
Message: <web.67668847f8229af4e83955656e066e29@news.povray.org>
William F Pokorny <ano### [at] anonymousorg> wrote:
>
> It's my view '//*3' isn't a mistake, but a valid comment which the
> parser should be ignoring no matter whether it's nested inside a /*..*/
> block comment or not.

That is an interesting alternate viewpoint! I had assumed that my //*3
was 'bad amateurish code-writing'. In other programming languages which use
the /*...*/ construct for comments, is //*3 regarded as a perfectly valid way to
write a *single line* comment in the way that I had in mind, without an extra
'separator' space before the  *3?

> Leroy's test case of:
>
> /* wrrtr
> //*3
> fdssdds
> */
> */
>
> is a good one because the integrated editor in the windows binaries must
> be ignoring '//' and anything after as a stand alone comment.

Yes, Leroy's is an interesting example; I did not test such a construct as that.
I re-wrote it a different way, to get a better understanding of your
explanation:

/* wrrtr
//*3
#declare BAR = 8;
*/
*/

#debug concat("\n","BAR = ",str(BAR,0,0),"\n") // This fails; there is no BAR as
a variable. It is simply part of the 'inner' comment block.

And the final additional */ closes the 'outer' comment block, avoiding the
original error message of "no closing comment found".

In my original scene, when my 'mistake' first triggered the error and presented
the fatal warning, I did think of just adding the additional 'required' */ as an
expedient way of solving the problem-- but I was not sure *where* to put it! (I
see now that I could have simply inserted it at the end of my big commented-out
code block, with no harm done.) But, that would have been too easy! and would
have prevented me from finding my own 'mistake' ;-)

>
> Your problem code is something the newer parser clipka coded up reports
> better than the older parser.

> The newer parser (in the POV-Ray master branch and a derivative of it is
> the parser used in yuqk)...

[I am running 3.8 beta 1 in Windows; sorry that I did not mention it earlier]
Did Clipka's newer parser make it into beta 2? Or was it 'backtracked' (not
included) in either of the betas, along with a few other previous features?


Post a reply to this message

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