Val returns 0 when it's not getting numbers

[fsw]

The problem is when evaluating a char (as string) Val returns 0:

Code: Select all

Val("0") ; returns 0
Val("1") ; returns 1
Val("2") ; returns 2
Val("3") ; returns 3
etc.
Val("a") ; returns 0

Wouldn't a -1 return value be better?
(since Val("-1") doesn't work anyway...)

Thanks for reading
fsw

[Kaeru Gaman]

nope, because the Value of the string is Zero, not minus one.
it has always been this way since the Function that returns a numerical Value of an alphanumerical string was invented.

try:

Code: Select all

Debug Val("-1")

... dunno what you have messed up.

note:

Code: Select all

Debug Val("$C85F")

Code: Select all

Debug Val("%101010101")

[UserOfPure]

Val, in all Basics, has always returned 0 if it starts with a non-digit. Many apps rely on this expected behavior, and to change it now would break a lot of code for no good reason.

(since Val("-1") doesn't work anyway...)

Huh? Returns -1 here, as expected. Works just fine.

[fsw]

Okay then return a #PB_ERROR constant value instead of zero.

Only because Basic's do something in a certain way doesn't mean it's the best way of doing things.

---

Now repeat after me: "Purebasic is NOT Basic" it's different - and that's why most users love it

[Fred]

The problem is you can't return a special value, as all values in the range are already possible. You would need another function (CheckNumber() or something) to do it properly.

[DarkDragon]

Okay then return a #PB_ERROR constant value instead of zero.

Only because Basic's do something in a certain way doesn't mean it's the best way of doing things.

But thats definately bad what you suggest. How would you differ from the value of the constant and the right value? Why don't you check yourself if the number is okay?

Lets say #PB_ERROR = -1234. How could you differ between Val("-1234") and Val("blubb")?

[fsw]

Will create my own function, thanks.

[UserOfPure]

.