On 12/21/24 04:25, Kenneth wrote:
> 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?
> 

Computer languages are legion... The strict answer is I don't know.

Both C and C++ (gnu) treat the //*3 (or //*) within a /*...*/ comment 
block as a stand alone comment and compile fine.

That said, the Ubuntu distribution shipped C and C++ vim/gvim syntax 
files DO mark the second slash ahead of the '*' character as a 
'potential error' when it is nested within a /*..*/ block style comment 
(***).

So, those supporting the C/C++ vim syntax files do consider the lack of 
a space after the '//' and ahead of a '*' character to be bad comment 
coding practice when within a block comment.

(***) - Something I didn't know until trying things just now :-). Maybe 
I'll take a look to see if I can adopt that checking for the yuqk SDL, 
vim syntax file as I do agree '//*' isn't good comment practice in 
languages supporting both the // and /*...*/ comment styles.

>> 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?
> 

IIRC. During clipka's return of some months after his first long period 
away, he 'backtracked' the parser to an earlier, non-new version - along 
with quite a bit of other code ahead of the two v3.8 beta releases. Both 
v3.8 betas are using the older parser.

Aside: This general 'backtracking' is also related to why we are seeing 
the recent boost library issues with newer linux / unix distributions 
when building v3.8 beta 2.

I've never compiled a complete list of 'stuff' backtracked. I was 
nervous at the time it happened as, during an intended final beta phase, 
we jumped backward to code states our community as a whole had not been 
running - for years. Today, I suppose it is what most of us running v3.8 
have been running since mid to late 2021...

Aside 2: Before I broke away with yuqk (formerly povr), I'd been the one 
running all the shipped v3.8 scenes (and additional test cases of my 
own) periodically during v3.8 development. To my recollection / 
knowledge this sort of more complete testing has never been done for the 
'backtracked' beta 1 & 2 releases. FWIW.

Bill P.

Post a reply to this message