QB64 Phoenix Edition v3.11.0 Released!

[bplus]

Can you imagine teaching kids to count in base 16 with this!

0 = 0
1 = 1
2 = 2
3 = 3
4 = 4
5 - 5
6 = -4
7 = -3
8 = -2
9 = -1

Yikes!

[bplus]

Look I know I am not going to change computer science with this stuff, just saying if you want consistency between number bases this is the way I would go. You don't need 2 sets of rules for base 10 and NOT base 10.

Sorry this isn't even about QB64pe versions... we'd have to go back in time and waste 1 decmal place for the sign.

[SMcNeill]

-&H1 ^ 2 (this is how you suggest writing it).

This is (-1)^2

This is subtract one: - &H1

a minus sign next to base letter indicates it's a negative number whereas a space or + sign indicates a positive value in my way of thinking for numbers beyond base 10 consistent with base 10 designations.

You look at the number and see the absolute value then read a - or (space or +) attached to left side to tell which side of 0 it resides on a number line.

So you'd have to start writing things such as 3 - -&H1?  

3 - &H1 would be different than 3 -&H1? (Which would error out I guess, because you were typing fast and missed that space?)

Or do you have to start writing it as 3 - (&H1), just to be safe?

How the heck is that any easier to keep straight and use?

Why not make it &H-1?  Put that minus on the inside of that $H?  Of course, you're no longer dealing with base-16 then, but dealing with base-16-plus-sign...

[mdijkens]

To be honest I've never been really interested if &h represented itself as a positive or negative decimal number. It's just a decimal representation that hardly never is relevant for your program.

Always when I used &h in my code it was for better readability of that specific value.
Mostly used for example with things like:
Color &hFF008080
SendCommand Chr$(&hFA)
If StatusBits And &h08 Then

I normally expect a program language to automatically type-cast to the needed format.
For example if Color function was defined something like 'void Color (uint32_t fcolor, uint32_t bcolor)' it would not matter what &hFFFFFFFF represents decimally because it would be type-casted to unsigned long.
Same would go for Chr$(uint8_t)
etc.

Not sure if this helps for a future way forward?

[bplus]

Why not make it &H-1? Put that minus on the inside of that $H? Of course, you're no longer dealing with base-16 then, but dealing with base-16-plus-sign...

Sure OK! if it makes things easier or -1 base 16? versus 1 base 16 on the other side of 0 on a number line.

[zaadstra]

Nice!

How to program:

PRINT "Parent directory full path: "; _FULLPATH$("../")            src:

if you want your.bas be working for Win and for Linux/Mac?  I mean, the slash ...

[zaadstra]

I've been playing a bit more with hex values

Code: (Select All)

Print &hFFFF
Print &hFFFFFFFF

Both print -1 now

But 

Code: (Select All)

Print Val("&hFFFF")
Print Val(&hFFFFFFFF")

Still print 65536 and 4294967295

While QBX (7.1, I don't have QB 4.5 anymore) prints -1 and -1

I still have 4.5 if you want it.

[a740g]

Nice!

How to program:

PRINT "Parent directory full path: "; _FULLPATH$("../")            src:

if you want your.bas be working for Win and for Linux/Mac?  I mean, the slash ...

QB64-PE will auto-correct slashed based on the platform.

For example, the above code will return the directory name with a forward slash on macOS and Linux. And it will return the directory name with a backslash on Windows.

See example 2 in  _FILES$ - QB64 Phoenix Edition Wiki for a way to manually handle path separators based on the OS.

[RhoSigma]

Nice!

How to program:

PRINT "Parent directory full path: "; _FULLPATH$("../")            src:

if you want your.bas be working for Win and for Linux/Mac?  I mean, the slash ...

QB64-PE will auto-correct slashed based on the platform.

For example, the above code will return the directory name with a forward slash on macOS and Linux. And it will return the directory name with a backslash on Windows.

See example 2 in  _FILES$ - QB64 Phoenix Edition Wiki for a way to manually handle path separators based on the OS.

Guess his question did rater target on the input string than on the result. If the input string uses backslashes like in windows on a LNX/MAC system, is it handled correctly or errors the backslash on LNX/MAC. That's indeed not detailed in the wiki, you just detail the result's behavior on different OS's.

But assume it works as in all other file related commands.

[a740g]

Nice!

How to program:

PRINT "Parent directory full path: "; _FULLPATH$("../")            src:

if you want your.bas be working for Win and for Linux/Mac?  I mean, the slash ...

QB64-PE will auto-correct slashed based on the platform.

For example, the above code will return the directory name with a forward slash on macOS and Linux. And it will return the directory name with a backslash on Windows.

See example 2 in  _FILES$ - QB64 Phoenix Edition Wiki for a way to manually handle path separators based on the OS.

Guess his question did rater target on the input string than on the result. If the input string uses backslashes like in windows on a LNX/MAC system, is it handled correctly or errors the backslash on LNX/MAC. That's indeed not detailed in the wiki, you just detail the result's behavior on different OS's.

But assume it works as in all other file related commands.

Yeah. You are correct. All our filesystem and file I/O functions and statements that take a file / path name does the auto-correct.