Riddle me this...

[Pete]

a$ = "0": b$ = "5"

PRINT a$ < b$

Result: -1, which is all well and good, but why won't QB64 accept it this way?

PRINT "0" < "5"

Pete ^^0^^

[Gets]

what's being compared in a$ < b$ ? It looks ordinary since you're using numbers, but you could also compare "dog" and "cat" the same way.

[Pete]

Nope, that's not it, because...

a$ = "dog": b$ = "cat"
PRINT a$ > b$
END

Result is -1, true, because strings are evaluated alphabetically, and d > c.

Pete

[FellippeHeitor]

Code: QB64: [Select]

1. PRINT ("0") < ("5")

That works, just don't ask me why. Parsing is a bitch and I have utmost respect for what Galleon did.

Riddle me this: did that work in QB4.5? Then we'll have to work around it.

[Pete]

I would appreciate it if someone with DOSBox QuickBASIC could check this out. I have one on my retired Win 7. If nobody posts soon, I'll try and fire it up, but no promises if it still will boot.

Fell, neat find on adding the parentheses! I did not know that was available.

Pete

[Cobalt]

QB45 ,through DOSBOX, is green across the board.
show -1 for each item
PRINT a$ < b$
PRINT "0" < "5"
and
PRINT ("0") < ("5")

[Pete]

Thanks for checking that.

Fell, drop everything you're doing right now, put you kid up for adoption, and get busy on this incompatibility immediately. Either that or take the family out for dinner and realize that no one else will ever stumble upon this WHOGAS inconsistency... or just let fluckin' luke take care of it. Forget Steve, he's on the clock already.

Pete :D

[TempodiBasic]

Hi
but it seems that Parser doesn't like  comparing costant string value!

see this  [ You are not allowed to view this attachment ]  
  [ You are not allowed to view this attachment ]  

but the issue is in the PRINT or in the < operator?

[FellippeHeitor]

PRINT is a special case for QB64 and as such it is processed internally differently. If you use literal string comparison in an IF statement, for example, it'll work.

Code: QB64: [Select]

1. IF "0" < "5" THEN
2.     PRINT "duh!"
3. END IF

[victorhugo]

in SDL works correctly

[SMcNeill]

in SDL works correctly

I would imagine this broke when auto-semicolon was added into PRINT.

In SDL, try:  PRINT “0”x”5”

You get an error...

In GL, PRINT “0”x”5” automatically adds semicolons to make that statement PRINT “0”; x; “5”.

I’d imagine (but can’t be 100% certain) that the insert semi-colon addition is what’s causing the discrepancy between the SDL and GL version.  Comparing the translated c-output in main.txt would probably verify the issue.

[victorhugo]

It is probable, but anyway SDL is still more consistent with the old versions created for DOS

[SMcNeill]

It is probable, but anyway SDL is still more consistent with the old versions created for DOS

Depends on what you’re comparing.  QB45 added semicolons between PRINT statements automatically; our SDL version didn’t.  It’s a trade of one incompatibility for another, with the only real difference being the GL version is being maintained and can be corrected, whereas the SDL version won’t be.  ;)