you can't claim "boasting rights" on that one I do not mean to. Val() is old and buggy, and should be avoided, in new code (if at all possible). The VAL() function is a very BASIC function and should not have the status deprecated. It is convient and has been part of the language from the...

marcov wrote:And who said QB was standard compliant to begin with ?

You'd have to go to TrueBASIC for that if I'm not mistaken. Victor just liked QB very much, as did many others at the time, including me. FreePascal came about in the same way, while TP was also not standard or ISO Pascal compliant.

The VAL() function doesn't understand '-&' as the start of a valid number format. The VAL() function understands what it is programmed to do. Currently, a minus+ampersand combination at the start is considered not-numerical, which I would consider inconsistent. I covered this and another incons...

sancho3 wrote:@munair:
Glad to see that this method is used by programmers other than me. It gives me some confidence.

The final functions are covered in a new thread. Confidence comes from testing. ;-)

There is always the possibility of a migration tool to make the transition to new incompatible concepts easier. Change is inevitable. Trying to hold on to 10+ years old concepts won't benefit the compiler and the language in general. More possibilities and new powerful features should always be cons...

It would be up to a parser/lexer to locate separators and isolate the code to be identified.

In regards to the keywords, I set up a very fast method of matching them. Including macros there are more than 500 of them. I have them in data statements and I read them into an array. They are already in alphabetical order but sorting them wouldn't take long if need be. I create an index as I am ...

Following a recent thread on code parsing, it became clear that evaluating source code is quite different from evaluating a simple input field if it comes to numeric values. The first requires a lexer or code parser, while the second would do with the VAL() function. To show you the difference, here...

Sure, but I wouldn't rule out the VAL() behaviour, because it's confusing if one doesn't know. But then again, VAL() isn't generally used to parse code. But it can be valuable if a user is required to input a valid number. Hence my proposal to have two different procedures. Worth a new tread I would...

Perhaps two procedures should be used: one to evaluate a specific string as would val do, and another to parse code.

You can check the first char. If it's a leading minus, eat it and pass the remainder of the string to val(). Then, if it's a valid number, negate it. This stems from the situation I explained above (the sign being part of the whole term, not the factor). It appears that FB is inconsistent here: dim...

The following string is also a valid number in FB and reports incorrectly in your code: ? isnumeric("-&hff") ? -&hff #print typeof(&hFF) #print typeof(-&hFF) I went by what VAL() returns and it appears that a minus sign before ampersand is invalid (returns 0): dim s as str...

In QuickBASIC it wasn't possible to use the VAL() function in a IsNumeric test without error trapping because of possible overflow errors (if the number held by a string would be very large). In FreeBASIC this is not a problem so a IsNumeric function could simply use VAL() or test for NULL: function...

Thanks for sharing.

Nice example.