PB/CC5.0 Differences

[Ian leonard]

Have just downloaded version 5 of PP.cc - looking forward to using it on my rather large PBcc4.04 program which compiles and works fine.

However when compiing this under version 5 I get the following error;
Error 459 : NEXT expected.

(Error positions itself onlast line of program - END FUNCTION statement form PBWIN)

This is strange as version 4.04 compiles the same source without an error - is verson 5 more fussey or is this a slight problem with the new version?

Where do I start looking as it's a big...big program.

Help..........

Ian

[George Bleck]

Hard to tell without code.. one tool I use to help is a code formatter.

Seomtimes its hard to tell where IF/THEN, SELECT CASE, DO LOOP, etc. begin and end.

Using a code formatter sometimes uncovers these errors quickly as you will see an outdented code line that went to far indicating a missing or misplaced pair.

I have my own code formatter in the download library (which I will be updating to one 5/9 compatible soon) but there are others in there as well which might be of use.

[Michael Mattias]

> S[o]mtimes its hard to tell where IF/THEN..

And heaven help you if you have mixed single-line IF...THEN with block IF...THEN ...END IF

[George Bleck]

BUSTED by the spleling police

EDIT: Btw way you missed the misused "to"... should have been "too"

[Ian leonard]

Dieeerence

No the point i am making is that the source is correct without For Next errors and complies OK using PBCC4.03/4 but only gives this error on the new PBCC50 compiler - what's going on ?

[Kev Peel]

Nobody can help without seeing some code. Try the suggestion of running it through a code formatter to see if the alignment is out.

[jcfuller]

No the point i am making is that the source is correct without For Next errors and complies OK using PBCC4.03/4 but only gives this error on the new PBCC50 compiler - what's going on ?

The only thing I can think of is it might be a name conflict in such a place that it falls completely through to the end??

James

[Michael Mattias]

Even if the error message is incorrect or misleading, the error simply MUST be in that procedure.

PB compiles everything procedure by procedure. If the error message is presented on the END FUNCTION statement you can be confident the source of the error is somewhere after the paired FUNCTION header.

I had one of these once drove me nuts. Turned out it was spotted by fresh eyes in about four seconds.... a spurious underscore at the end of one line.

You know what else can get you this error?

IF whatever
  many lines of code
  FOR  
      more lines of code 
  NEXT 
END OF

[John Petty]

Ian
It would appear that the FOR/NEXT code has been rewritten, though there are no actual stated changes in functionality. Perhaps the new compiler is checking the conditions more thoroughely. If it was a problem an IF THEN block the compiler error was missing FOR not missing NEXT
John

[Bud Durland]

I vote with James -- the most likely culprit is a variable name that is now a keyword to the new compiler.

[Barry Erick]

The alignment is what is needed. Every inner block must be finished before the next outter block is. Next expected simply means some other item showed up.. a end if, loop, whatever. Sometimes printing out the function and connectings lines to each block will show the missing item. Most likely there is a new keyword in there doing you in.

A new keyword can be shown easily in the IDE as keywords are highlighted. Is anything showing in the highlight color that did not before?

[Peter Lameijn]

Could also be that because of the new added keywords, a line of your code is now treated as keyword, while it previously was just a line of code...

[Chris Holbrook]

Where do I start looking as it's a big...big program.

Lets assume it is, in the compiler's opinion, a single error. Comment out about half the procedural code - leaving the FUNCTION or SUB and END [FUNCTION|SUB] statements. The unit of commenting out is the SUB or FUNCTION. PB IDE has good tools for toggling comments on blocks of code.

Attempt to recompile. If it recompiles, then the fault lies in the half which you commented out. Otherwise, uncomment that half, comment out the other half and try again.

Then proceed to isolate the problem futher by successive binary divisions until you find the FUNCTION or SUB containing the problem.

[keith shelton]

I found that count is now a key word.
KS

[Anthony Giambalvo]

Changes in Next Statement

Is it possible the problem is caused by a change in the way the Next statement is handled? In PBCC 4, you could use NEXT A,B to end two FOR statements with one line. In PBCC 5, that does not work and is understood to end only the inner FOR/NEXT loop.

-- Anthony Giambalvo

[Joe Byrne]

I found that count is now a key word.
KS

Ah, I don't think so.

FUNCTION PBMAIN() AS LONG
    FOR count& = 1 TO 10
        Count$ = Count$ + STR$(Count&)
    NEXT
    ?Count$
END FUNCTION

Compiles and runs just fine with PBWin9 and PBCC5

[StanHelton]

...
Compiles and runs just fine with PBWin9 and PBCC5

Count and Count& are 2 different variables.

OTOH, you are correct that COUNT is legit as a variable name in CC5 and PB9.

Take a look at this link for more details:

http://www.powerbasic.com/support/pb...ad.php?t=38450

Stan

[José Roca]

It is a keyword but not reserved. Secondary keywords aren't usually reserved.

[Rodney Hicks]

It is a keyword but not reserved. Secondary keywords aren't usually reserved.

I sorta, kinda, almost thought that reserved words were sorta Secondary keywords. I have used the term Reserved for any word that highlights in the editor, not just words used in conjunction with other words eg. ADD, ON etc.

Might be wise not to use them if there's a chance of them becoming more utile to the PB language, which IMO seems to be the case.

[Jim Robinson]

mcm wrote:

You know what else can get you this error?

Yeah, kind of...