Peter N Lewis wrote:
At 18:22 +0200 29/9/04, Frank Heckenbach wrote:
So my proposal is to add (now or later):
function String2Num(???) (const s: String; var n: <numeric type>): Boolean;
Comments?
Isn't that just a utility function? I suspect that sort of thing belongs more in a utility unit that users can include if they desire.
Then we'd need one for each type (and subrange types would generally be impossible since there are "infinitely" many of them). As a built-in function, the compiler could handle all integer and real types.
Especially since there are hundreds of ways of converting a string to a number and the requirements change depending on the usage. For example:
Do you strip spaces?
No, the user can do this before calling the function, if desired (e.g., by using `TrimBothStr').
What decimal separator do you use (".", "," or " " (space))? What thousand separator do you allow if any (".", "," or " " (space), "'", none)?
The real syntax as specified in the standards (plus BP extensions, according to dialect options as usual).
What about stripping a currency symbol? What about supporting exponent symbols like K, M, G, T? Metric or Computer (1024) multipliers?
Up to the user.
What about hex, octal, binary support? And the ability to specify a default base?
As defined in the respective standards (EP: `base#number') and dialects (BP: `$' for hex).
It's all the same we have for `Read[Ln|Str]' and `Val' already. (I don't really plan to enhance the actual reading routines, just provide another interface to them.)
In my code, I have about half a dozen different String2Num functions and I'm not all that serious about internationalization and hardly ever let users enter numbers directly.
In my code, I use `Val' most of the time (with numbers entered by users, read from files and what not), and apart from the clumsy procedure-style syntax, it's alright -- apart from monetary input for which I have a separate routine (http://fjf.gnu.de/misc/moneyutils.pas -- not very general yet) which uses `Val' in turn.
Frank