On 6/21/24 05:40, Bald Eagle wrote:
>> 1)
>>    Result
>>
>>           #end // end macro Gamma
>> #end
>>
>> Those lines should be:
>>
>>           #end
>>   Result
>> #end // end macro Gamma
> That's because I left that extra #end in there to just try to get it to run
> without complaining about the initial "missing" #end statement.

To my eyes and a quick check the parser was correct to complain. Without 
that 'extra' #end you have a missing #end statement in the code you 
posted. That 'extra' one fixed that, but Result ended up in the wrong 
spot - about which the compiler is also right to complain.

I agree though, the error message is confusing. In my yuqk fork, I can 
add another line of explanation making the entire error message:

Parse Error:
#declare of float, vector, and color identifiers require semi-colon ';' 
at end. As do equivalent #local identifier definitions and the #version 
setting. This error is sometimes issued where an #end statement 
incorrectly follows a floating, defined identifier. The problem may 
involve lines of prior code.

Is that error message more helpful?

I see Kelumden answered your C++ question (Thank you). Apologies. I 
spaced that you'd asked it.

---

I'll offer up two tricks I use. One when translating from c/C++ to SDL 
or playing with potential changes to the POV-Ray(yuqk) code base. The 
other when trying to match all of SDL's opening directive blocks with 
their #end(s).

1) For smallish questions about c/C++ code, compile and run a small 
example. The whole of the recently announced f_catenary() function was 
written this way prior to inserting it into the yuqk source code. 
Install a C++ compiler if you've not.

For the question you asked, I'd create a file my.cpp containing:

//---
#include <iostream>
#include <string>

int main()
{
     double Result = 1.0;
     int    Y      = 1;

     Result *= Y++;
     std::cout << std::endl << Result << std::endl;

     Result *= Y++;
     std::cout << std::endl << Result << std::endl << std::endl;
}
//---

Compile with:

	g++ my.cpp

or equivalent. Without setting more options, the executable on unix like 
systems will be 'a.out'. In a terminal window type:

	a.out

And you'll see:

1

2

Trying ++Y is an interesting experiment too.

2) When really stumped on #end matching, employ an editor which matches 
braces, parens, brackets or the like. It doesn't need to be the editor 
you use day to day. I'm using 'vim via gvim' on my Ubuntu machine.

Edit a temporary file called my.pov. I started by boiling the code you 
posted for Gamma() down to what needs #end matching. I then added open 
'{' and close '}' characters in a more or less outside -> inward order.

#macro Gamma (X) {
     #if (X <= 0.0) {
     #end }

     #if (X < 0.001) {
     #end }

     #if (X < 12.0) {
         #if (arg_was_less_than_one) {
         } #else {
         #end }

         #for (i, 0, 7) {
         #end }

         #if (arg_was_less_than_one) {
         } #else {
             #for (i, 0, n) {
             #end }
         #end }

         #if (X > 171.624) {
         #end }
     #end }
#end }

When lucky, mistakes will immediately be highlighted in red. When not - 
say, for example, #end(s) are in some way matching incorrectly - I place 
the cursor at each opening '{' or closing '}' brace in turn. Its 
matching brace will be highlighted(*) in a like color to the one at my 
cursor - and I check that matching is correct for each matching pair in 
turn.

Yes, I'm managing to stay cool, but one sure feels the heat & humidity 
on stepping outside! :-)

Bill P.

(*) - In larger bits of code there are ways to find and move to the 
currently matching brace.

Post a reply to this message