> i think Jochen has a nice routine like that it would be a nice addition to the masm32 library
No, its a nice addition to MasmBasic, that is what JJ wrote it for. A library for MASM needs much finer granularity to avoid duplication and redundancy, ...
Mixing Masm32 and MasmBasic is perhaps not a good idea, I agree.
Val(My$) (and
MovVal) are "all you can eat" macros that emulate the behaviour of the corresponding HLL (in this case,
GfaBasic).
There is an issue with the design logic, however.
First, we tend to say "it's better to have a high-speed specialised algo than a slow allrounder". Right, but MasmBasic's Val/MovVal, while able to "eat" decimal, bin and two hex formats, and correctly handling whitespace, is five times as fast as the current atodw... Now that will change with the superfast new Masm32 atodw, fine.
Second, "I want to be sure the algo does only what I want it to do". I.e. atodw should not convert "-123" if the documentation says "unsigned decimal" (and one can argue whether writing "DWORD" is sufficient). However, if you feed "-123" to atodw, then the algo should complain, otherwise that "design advantage" is nil.
Last but not least, I still believe that even the experienced programmer who starts with Masm32 needs a very explicit warning that atodw, if fed with " 123 ", produces rubbish. Not knowing that behaviour produces the kind of bug that makes us spend sleepless nights, and it would be easy to avoid it.
