[jallib] r3159 committed - Benefits of the new string_to_dword function: saves a temporary dword,...

[jal...@googlecode.com]

Revision: 3159
Author: karl...@yahoo.com
Date: Fri Jan 4 00:26:18 2013
Log: Benefits of the new string_to_dword function: saves a temporary
dword, uses no divisions and only half the multiplications. Stops on
non-number characters.
http://code.google.com/p/jallib/source/detail?r=3159

Modified:
/trunk/include/jal/strings.jal

[mattschinkel]

I think non-number characters should be ignored, instead of stopping on them.

 

for example the string: "$123,456" should be confertable to a number.

 

Matt.

[Oliver Seitz]

I think non-number characters should be ignored, instead of stopping on them.

 

for example the string: "$123,456" should be confertable to a number.

Can be discussed, of course. Your example string would, with the old function, result to −118773544 (or 4176193751 as unsigned) for "$" would count -12 and "," would count -4. So the old version had just given senseless results, stopping seemed more sensible to me.

I've used it to parse a string like

"     12=1446"

It's meant for presets which can be typed in via serial console and stored in data eeprom.

Parsing is very simple. First, a for loop replaces every " " with "0". Then, the number is evaluated which stops at the "=", and I have the address which is to be changed.

Then, a byte*x variable laid over the string is >>8 until the first character is a "=". Then, the first character is set to "0", the string is evaluated again, and I have the value which should be stored at the address just found.

Yes, could be done by replacing the "=" with ASCII_NULL. How about this: Like in jal source code, underscores are ignored, any other char stops the conversion? Your example could be easily converted to "_123_456" without moving parts of the string, which can be difficult (and error-prone) indeed.

Ok, I could live with stopping at ASCII_NULL and ignoring any other non-number char.

Any additional opinions?

Greets,

Kiste